[Python-de] Übersetzer gesucht

[Diez B. Roggisch]

> Warum wird dort eigentlich so viel umgeschmissen?
> Sollte man das alles, bei einer Programmiersprache, die auch im
> kommerziellen bzw. professionellen Gebrauch bestehen soll, nicht ein
> bisschen vorsichtiger sein?

Du verwechselst hier die  Einführung neuer Sprachfeatures und damit 
verbundener notwendiger innerer Strukturen mit der Entfernung von alten 
Zöpfen.

Python ist sehr abwärtskompatibel bei major releases. Es ist sehr 
selten, das alter Code bricht. Und für radikale Ideen gibt es Python3000.



> Irgendwie kommen mir die ganzen Ideen die dazu.. gepfriemelt will ich jetzt
> nicht sagen.. implementiert werden, bzw. den Gedanken möglichst viele
> Programmierparadigmen unterzubringen, ein wenig inkonsistent und nach
> ersten Anzeichen einer "Featureitis" vor? :o) Wenn du jetzt zudem auch
> sagst, mit nem Handbuch vll. eher auf die neue Version warten? Vll. erfährt
> man dann an der Arbeit daran, was in 2.6 wieder alles geändert werden soll?


> 
> Gibt es jemand, der mir dieses Gefühl austreiben kann? Noch bin ich ein
> Newbie, und noch schwanke ich zwischen Python und Ruby ;o)
> (welches nur beständig erweitert, aber nicht umgekrempelt wird, und
> konsequent objektorientiert arbeitet ohne Ausnahmen oder Hacks..)
> Will ja keinen Flamewar anzetteln, will nur das blöde Gefühl loswerden ;o)

Wo siehst du denn Hacks und inkonsistenzen? Nicht das es letztere 
bestimmt gibt, viele bemängeln ja das fehlen von Codeblöcken und 
anderem. Aber seid wann sind generator-expressions oder newstyle-classes 
Hacks? Das Gegenteil ist doch eher wahr: ohne sowas muss man  ggf. 
"drumrumcoden", bis hin zu den in JAVA allgegenwärtigen Codegeneratoren.

"Nee, decoratoren können wir nicht und brauchen wir nicht. Aber mit ein 
paar extra compilern, byte-code-injection & etwa 100 xml-files machen 
wir das eh viel besser!". Sicher.

Und wo ich immer _ganz_ hellhörig werde ist wenn jemand sowas wie
"konsequent OO" in den Mund nimmt. OO ist schön und gut, aber nicht die 
SilverBullet, die viele in einer relogiösen Verklärung darin sehen. Eine 
Sprache wie JAVA die einen darauf festlegt und dann sowas dämliches wie

class Predicate {
     public boolean apply(Whatever foo);
}

von einem verlangt, weil sie nicht in der lage ist mit Funktionen als 
Werten umzugehen... na danke.

Und was Ruby angeht, da gibt es auch bei nur oberflächlicher Betrachtung 
auch so einige Warzen:

http://www.martinfowler.com/bliki/HumaneInterface.html

ZB ist die string.join methode auf Arrays definiert. Das ist mir in den 
ersten zwei Minuten schon aufgestossen. Wie konsequent OO ist es denn, 
generische Containerklassen etwas über das zusammenkleistern von Strings 
beizubringen?

Nix gegen Ruby - und mehr als ein bisschen gespielt habe ich damit auch 
noch nicht. Aber der Weisheit letzter Schluiss ist das auch alles nicht.

MfG Diez