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.
Was genau hat der Link mit dem Thema zu tun? Solltest Du auch 2to3 anspielen wollen?
Abgesehen davon: Manchmal muss man eben alte Zöpfe abschneiden, um sich zu verbessern. Afaik war das beim Wechsel von 1.x auf 2.x auch so! Also stimmt die Aussage im Artikel nicht einmal ...
Python 2.6 existiert. Wer noch nicht wechseln möchte, der tut es einfach nicht. Er sollte eben die Hinweise in der Python-Doku beachten und seine Applikationen so anpassen, dass eine automatische Konvertierung funktionieren kann.
Die kranke Architektur der "kompatiblem PCs" geht auf mangelnden Zopfabschneidmut zurück, ebenso hat sich manche Schwäche von DOS bis Windows so eine Nische erhalten...
Der Mensch ist von Natur aus faul, konservativ. Wenn man etwas ändern will, benötigt dies kurzfristig mehr Aufwand/Energie. Es ist ineffizent etwas 'offentlichtlich' unnötiges zu ändern, weil man den Nutzen nicht sieht.
Nunja aber natürlich ist es effizienter wenn man weiter als 10 Minuten denkt, sodass man sich das Leben evlt. längerfristig leichter machen könnte, was dann wieder Energie sparen würde, also effizienter wäre. Das ist jedoch wieder anstrengend, was im Widerspruch zur Faulheit steht...
Siehe auch
http://lists.trolltech.com/qt-solutions/2006-03/thread00001-0.html
Ich finde das schlimm.
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
Abgesehen davon: Manchmal muss man eben alte Zöpfe abschneiden, um sich zu verbessern. Afaik war das beim Wechsel von 1.x auf 2.x auch so! Also stimmt die Aussage im Artikel nicht einmal ...
Python 2.6 existiert. Wer noch nicht wechseln möchte, der tut es einfach nicht. Er sollte eben die Hinweise in der Python-Doku beachten und seine Applikationen so anpassen, dass eine automatische Konvertierung funktionieren kann.
SCNR
Die kranke Architektur der "kompatiblem PCs" geht auf mangelnden Zopfabschneidmut zurück, ebenso hat sich manche Schwäche von DOS bis Windows so eine Nische erhalten...
Der Mensch ist von Natur aus faul, konservativ. Wenn man etwas ändern will, benötigt dies kurzfristig mehr Aufwand/Energie. Es ist ineffizent etwas 'offentlichtlich' unnötiges zu ändern, weil man den Nutzen nicht sieht.
Nunja aber natürlich ist es effizienter wenn man weiter als 10 Minuten denkt, sodass man sich das Leben evlt. längerfristig leichter machen könnte, was dann wieder Energie sparen würde, also effizienter wäre. Das ist jedoch wieder anstrengend, was im Widerspruch zur Faulheit steht...
Bei Informatikern ^10