Es ist einfach unsäglich, wenn einem das Fundament so einfach unter dem Arsch weggezogen wird. Wird es doch nicht!!! Python 2.6 existiert. Wo fehlt es denn Deinem Arsch? Nebenbei geht es bei dem Artikel um 3.1 - 3.0 ist schon letztes Jahr erschienen ...
Warum hat es wohl so lange mit KDE4 gedauert? KDE4 ist etwas anderes als Python. Wesentlich komplexer und in viele Komponenten aufgeteilt. Die Sprache Python ist dagegen ein sehr kompaktes Paket und eher mit dem Kernel zu vergleichen. Diesen wechselt man ja auch öfter, ohne das es solche Beschwerden gibt. Über die Release Politik von KDE kann man natürlich streiten (auch wenn ich hinter dem Konzept stehe), aber man erkennt doch auch dort, wie schnell und stark die aktuelle Entwicklung voran schreitet. Guido hat Python sicherlich nicht zu seinem Nachteil weiter entwickelt. Ich bin da sehr opitmistisch, dass man mit Python 3.x noch angenehmer proggen kann. Dass dazu eben alte Zöpfe abgeschlagen werden müssen ist mir klar.
Und jetzt fängt Python auch schon wieder an "Auch schon wieder" ... aha, das letzte Mal hast Du auch schon erlebt und bedauert? Dann muss ja Python 2.x etwas grauenvolles für Dich sein!
Von Christopher Roy Bratusek am Mi, 1. Juli 2009 um 10:46 #
>> Es ist einfach unsäglich, wenn einem das Fundament so einfach unter dem Arsch weggezogen wird. >> Wird es doch nicht!!! Python 2.6 existiert. Wo fehlt es denn Deinem Arsch? Nebenbei geht es bei >> dem Artikel um 3.1 - 3.0 ist schon letztes Jahr erschienen ...
>> Und jetzt fängt Python auch schon wieder an >> "Auch schon wieder" ... aha, das letzte Mal hast Du auch schon erlebt und bedauert? >> Dann muss ja Python 2.x etwas grauenvolles für Dich sein!
Danke für deinen Beitrag zu den fortunes-prolinux :-))
ich denke, dass die änderungen in python3 sind nicht schwerwiegend genug um eine inkompatibiltät zu rechtfertigen. ich hätte mir für py3 folgendes gewünscht:
- kick GIL (siehe google's unladen swallow) - optionale statische typisierung - fest vorgegebenes standard installationssystem - abstract base classes
ich denke, dass die änderungen in python3 sind nicht schwerwiegend genug um eine inkompatibiltät zu rechtfertigen. Und das hast Du auf Interpreter-Ebene genau analysiert? Ich persönlich vertraue da auf die Entwickler, dass sie nicht unnötig Inkompatibilitäten einbauen, ohne triftigen Grund ...
Wenn du python so großartig findest solltest du wissen, dass die statische Typisierung nicht in das one-right-way Konzept passt. Ohne das werden auch abstrakte Basisklassen sinnlos, oder was willst du damit?
Weil es eine alternative wäre, und Python versucht nur eine Lösung pro Problem von Haus aus zu liefern. Deswegen ist auch Einrückung vs Klammern nicht optional.
Wer Flexibilität will (wenn auch nicht unbedingt zu diesen Themen) ist sicher bei Ruby besser aufgehoben.
Python-Zen ist eine Orientierung, Good Practices, kein Zwang. Python hat soviel redundantes und flexibles, würde man wirklich zwanghaft versuchen nur noch einen Weg anzubieten, die Sprache wäre vollkommen unbenutzbar.
Das ist nur halbwahr. Python schränkt sich natürlich auch nicht künstlich ein, will aber trotzdem wirklich nur einen offensichtlichen Weg anbieten. Das heisst nicht unbedingt das es nicht einen anderen geben kann, aber auch ganz klar das immer ein Weg der richtige ist. Ein rumgeschlabber "mit option x wird es so, mit option y so, beides ist ok", will man eigentlich nicht.
There should be one-- and preferably only one --obvious way to do it.
Es gilt sogar das gegenteil. Erst durch Flexible Konstrukte ist es überhaupt möglich die Wege zu beschränken. Man braucht eben nicht für jede Abzweigung und jeden Fall eine eigene Funktion, ein separates Statemant, sondern switcht die Vorhanden einfach passend zusammen.
Aber auch hier gilt: offentsichtlich ist was die masse kennt. Eingebaut wird was nutzen bringt. Richtlinien sind kein zwang, sondern nur Orientierungen.
KDE4 beinhaltete den Umstieg von Qt3 auf Qt4, da war ein Beibehalten des Fundaments überhaupt nicht möglich. Außerdem musste vieles einfach ersetzt werden, um für die Zukunft gerüstet zu sein, z.B. arts.
Es ist einfach unsäglich, wenn einem das Fundament so einfach unter dem Arsch weggezogen wird.
Warum hat es wohl so lange mit KDE4 gedauert ?
Und jetzt fängt Python auch schon wieder an
Wird es doch nicht!!! Python 2.6 existiert. Wo fehlt es denn Deinem Arsch? Nebenbei geht es bei dem Artikel um 3.1 - 3.0 ist schon letztes Jahr erschienen ...
Warum hat es wohl so lange mit KDE4 gedauert?
KDE4 ist etwas anderes als Python. Wesentlich komplexer und in viele Komponenten aufgeteilt. Die Sprache Python ist dagegen ein sehr kompaktes Paket und eher mit dem Kernel zu vergleichen. Diesen wechselt man ja auch öfter, ohne das es solche Beschwerden gibt. Über die Release Politik von KDE kann man natürlich streiten (auch wenn ich hinter dem Konzept stehe), aber man erkennt doch auch dort, wie schnell und stark die aktuelle Entwicklung voran schreitet.
Guido hat Python sicherlich nicht zu seinem Nachteil weiter entwickelt. Ich bin da sehr opitmistisch, dass man mit Python 3.x noch angenehmer proggen kann. Dass dazu eben alte Zöpfe abgeschlagen werden müssen ist mir klar.
Und jetzt fängt Python auch schon wieder an
"Auch schon wieder" ... aha, das letzte Mal hast Du auch schon erlebt und bedauert? Dann muss ja Python 2.x etwas grauenvolles für Dich sein!
>> Wird es doch nicht!!! Python 2.6 existiert. Wo fehlt es denn Deinem Arsch? Nebenbei geht es bei
>> dem Artikel um 3.1 - 3.0 ist schon letztes Jahr erschienen ...
>> Und jetzt fängt Python auch schon wieder an
>> "Auch schon wieder" ... aha, das letzte Mal hast Du auch schon erlebt und bedauert?
>> Dann muss ja Python 2.x etwas grauenvolles für Dich sein!
Danke für deinen Beitrag zu den fortunes-prolinux :-))
Wo kann man die denn einsehen?
Hier könnt ihr eure Vorschläge los werden: Klich mich
- kick GIL (siehe google's unladen swallow)
- optionale statische typisierung
- fest vorgegebenes standard installationssystem
- abstract base classes
ansonten thumbs up, python ist großartig.
Und das hast Du auf Interpreter-Ebene genau analysiert? Ich persönlich vertraue da auf die Entwickler, dass sie nicht unnötig Inkompatibilitäten einbauen, ohne triftigen Grund ...
Weil?
Deswegen ist auch Einrückung vs Klammern nicht optional.
Wer Flexibilität will (wenn auch nicht unbedingt zu diesen Themen) ist sicher bei Ruby besser aufgehoben.
Du solltest weniger schlechter Module importen
reduce() als funktionale Alternative zur imperativen Schleife?
Python-Zen ist eine Orientierung, Good Practices, kein Zwang. Python hat soviel redundantes und flexibles, würde man wirklich zwanghaft versuchen nur noch einen Weg anzubieten, die Sprache wäre vollkommen unbenutzbar.
BTW Flexibel is Beautiful is better than ugly
Das ist nur halbwahr. Python schränkt sich natürlich auch nicht künstlich ein, will aber trotzdem wirklich nur einen offensichtlichen Weg anbieten. Das heisst nicht unbedingt das es nicht einen anderen geben kann, aber auch ganz klar das immer ein Weg der richtige ist. Ein rumgeschlabber "mit option x wird es so, mit option y so, beides ist ok", will man eigentlich nicht.
There should be one-- and preferably only one --obvious way to do it.
Es gilt sogar das gegenteil. Erst durch Flexible Konstrukte ist es überhaupt möglich die Wege zu beschränken. Man braucht eben nicht für jede Abzweigung und jeden Fall eine eigene Funktion, ein separates Statemant, sondern switcht die Vorhanden einfach passend zusammen.
Aber auch hier gilt: offentsichtlich ist was die masse kennt. Eingebaut wird was nutzen bringt. Richtlinien sind kein zwang, sondern nur Orientierungen.
Readability counts