Das deutsche Python-Forum

Weiß jemand, wie weit die da sind, bzw wann 2.7 released werden soll?

http://www.python.org/dev/peps/pep-0373/ ist da nicht sehr hilfreich.

http://mail.python.org/pipermail/python ... 89943.html

In dem Thread nennt Martin v Loewis den Zeitraum April - Oktober 2010.

Von den Check-ins her muss ich sagen, dass ich den Eindruck habe, dass noch nicht allzu viel passiert ist (das nicht auch nach 2.6 portiert wurde). Dass SVN vor ein paar Wochen mal gestorben ist (und eine Weile tot blieb) war da sicherlich nicht allzu hilfreich. Daneben sind auch noch Kraefte bei der Mercurial-Migration gebunden.

Aber warum hast du es denn so eilig? Python2.6 ist doch noch nichtmal voellig angekommen.

cofi hat geschrieben:Aber warum hast du es denn so eilig? Python2.6 ist doch noch nichtmal voellig angekommen.

collections.OrderedDict

oder: '{}{}'.format('a','b')

Viel interessanter finde ich, wie sich der 3er-Zweig entwickelt. Vielleicht wird ja am Ende solange über `__future__` & Co zurückportiert bis alle P3K-Features in 2.x angekommen sind.

snafu hat geschrieben:Viel interessanter finde ich, wie sich der 3er-Zweig entwickelt. Vielleicht wird ja am Ende solange über `__future__` & Co zurückportiert bis alle P3K-Features in 2.x angekommen sind.

Vielleicht kann man ja auch demnächst in Python 3 über __past__-Importe das alte Verhalten zurückbekommen.

Hab ich fast in allem was ich neu schreibe.

DasIch hat geschrieben:

Code: Alles auswählen

from __future__ import unicode_literals, print_function

Hab ich fast in allem was ich neu schreibe.

Dito.

Wobei ``__past__`` eher ``__old_mistakes__`` heißen sollte...

(die Zahl war jetzt willkürlich)

um nicht den parser umschreiben zu muessen sollte es vielleicht heissen:

jbs hat geschrieben:fifteenhundretandfour

100 == hundred
MfG
HWK

wohl eher

Darii hat geschrieben:

Code: Alles auswählen

from __past__ import good_old_times

Sinnlose Keywords und zu Bugs führende Unterscheidung zwischen Bytestrings und Unicode? Achja, zwei verschiedene Objektmodelle und viele doppelte Funktionen (einmal in normaler Variante und einmal in x oder i-Version)?

Ja, ne, früher war alles besser.

Wird 2.7 eigentlich noch langsamer als 2.6?

hendrikS hat geschrieben:Wird 2.7 eigentlich noch langsamer als 2.6?

Wenn sie Computed Gotos aus 3.1 portieren wohl eher nicht.

hendrikS hat geschrieben:Wird 2.7 eigentlich noch langsamer als 2.6?

Wäre doch eine gute Strategie, um die Leute in Richtung 3.x zu stoßen (vorausgesetzt, diese wird eher schneller als langsamer).

Stefan

@sma: Meinst du wirklich? Meistens fallen Pythons Geschwindigkeitsdefizite doch gar nicht auf. Und für komplizierte Berechnungen eignet sich bekanntlich NumPy ganz gut. Ich könnte mir das nur beim Zugriff auf extrem große Datensätze (sprich: sehr große Wörterbücher, Sets oder Listen) vorstellen, falls es nicht auch dafür irgendein Spezialmodul gibt, das in C implementiert ist. Ich lasse mich aber gerne eines Besseren belehren.

Naja, Parser sind in Python auch nicht sonderlich schnell. Ich war letztens erstaunt wie fürchterlich lange Python für eine 7 MB große Textdatei gebraucht hat, zumindest auf dem 2,4 GHz (!) Celeron (es ist übrigens erstaunlich was L2 Cache ausmachen kann: mit 128 KB dauerte das Parsen ca. 90 Sekunden, mit 256 KB auf einem etwas langsameren Pentium 4 ca. 30% weniger und mit 2048 KB auf einem noch langsameren Core 2 nur 10 Sekunden). Habe echt überlegt, den Parser dann in C auszulagern (oder in OCaml, aber das gibt an allen Ecken und Enden Probleme, obwohl Parsen mit OCaml sicherlich viel angenehmer als in C ist).

snafu hat geschrieben:Meistens fallen Pythons Geschwindigkeitsdefizite doch gar nicht auf. Und für komplizierte Berechnungen eignet sich bekanntlich NumPy ganz gut.

Die Frage von hendrikS dürfte vor dem Hintergrund seiner aktuellen (unangenehmen) Erfahrungen mit der Geschwindigkeit von 2.6 im Vergleich zu 2.5 auf den SPOJ-Rechnern zu verstehen sein: Da wurde vor ein paar Tagen auf 2.6 upgedatet und seitdem lässt sich erstens psyco nicht mehr nutzen und zweitens ist 2.6 je nach Algorithmus erheblich (meist aber nur ein wenig) langsamer als der gleiche Code unter 2.5. Da NumPy dort nicht verwendbar ist, es für die Lösung der Problemstellungen Zeitlimits gibt, die sich in der Regel an Sprachen wie C/C++ orientieren und man es teils mit enormen Mengen an I/O zu tun hat, lassen sich zahlreiche Aufgabenstellungen von SPOJ nunmehr mit Python schlichtweg überhaupt nicht mehr lösen und das ist frustrierend ...

Ja, hier http://www.spoj.pl/forum/viewtopic.php? ... e76784ef08
stehen die Fakten. Und ich war speziell über die 78 Prozent fast schon schockiert. 2.6 hat doch eigentlich nur geringfügige Änderungen. Wie können dann solche Verschlechterungen entstehen. Im Moment würde ich sagen "Lang lebe 2.5!"
Machen die Python Entwickler eigentlich Tests hinsichtlich Performance? Oder wird einfach draufzu gehackt. Hauptsache es geht.
Selbst alle grossen komerziellen Anbieter von Software haben doch inzwischen erkannt, dass Geschwindigkeit/Zeit ein Faktor ist. Schade, dass dieser Trend bei Python noch nicht angekommen ist.