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.
python 2.7
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
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.
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.
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
Vielleicht kann man ja auch demnächst in Python 3 über __past__-Importe das alte Verhalten zurückbekommen.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.
Code: Alles auswählen
from __future__ import unicode_literals, print_function
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Dito.DasIch hat geschrieben:Hab ich fast in allem was ich neu schreibe.Code: Alles auswählen
from __future__ import unicode_literals, print_function
Wobei ``__past__`` eher ``__old_mistakes__`` heißen sollte...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Code: Alles auswählen
from __anno__ import 1999_failures
um nicht den parser umschreiben zu muessen sollte es vielleicht heissen:
Code: Alles auswählen
from __anno__ import fifteenhundretandfour
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
wohl eher
Code: Alles auswählen
from __past__ import good_old_times
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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)?Darii hat geschrieben:Code: Alles auswählen
from __past__ import good_old_times
Ja, ne, früher war alles besser.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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 ...snafu hat geschrieben:Meistens fallen Pythons Geschwindigkeitsdefizite doch gar nicht auf. Und für komplizierte Berechnungen eignet sich bekanntlich NumPy ganz gut.
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.
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.