Für welche Pakete sich Python-User einen 3.x-Port wünschen

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

... sagt diese Seite: http://www.python.org/3kpoll

Django führt zur Zeit mit großem Vorsprung (535 vor 319). Ernüchternd ist da dann eher das durchaus ehrliche "What does this poll mean? Off-hand, nothing: nominating a package will not mean that its authors now start porting it to Python 3." Aber vielleicht sehen die Django-Autoren das ja als Ansporn, einen 3.x-Port vor TextMate 2.0 oder Duke Nukem zu beginnen ;)

Ansonsten sind das aber alles eher Sachen, die mich persönlich nicht so interessieren. Allerdings bin ich auch kein großer Paket-Nutzer. Ich würde mir ja lxml wünschen, aber dafür gibt es schon eine 3.1-Version. Kann man irgendwo die beliebtesten Pakete von pypi sehen? Mir fällt eigentlich nichts weiter ein, was ich unbedingt bräuchte.

Stefan
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Das sind aber auch ziemlich wenige Votes... Pi mal Daumen 2000. Nicht sonderlich repräsentiativ, finde ich.

Ist das Problem mit den ganzen WSGI-Libraries nicht, dass es noch keinen anständigen Standard für Python 3 mit WSGI gibt (hinsichtlich Unicode-Strings/Byte-Strings)? Es gibt irgendwie mehrere Ansätze, PEP 3333 und PEP 444 wenn ich mich richtig entsinne. Wenn ihr mich fragt muss man WSGI einmal komplett über den Haufen werfen. Da sind so viele Design-Fehler drin und dazu noch ist es auf beiden Seite umständlich zu handhaben... das wäre doch jetzt die Chance; durch Python 3 wird doch eh alles inkompatibel -- warum macht das keiner?! Armin Ronacher hat ja mit diesem Web3 (oder so) einen Vorschlag eingebracht, der geht mMn in eine gute Richtung (ist aber immer noch viel zu kompliziert).

Ehrlich gesagt sehe ich für mich gar keinen Grund auf Python 3 umzusteigen. Klar, Unicode-Überall(tm) ist genial; aber sonst bringt es nicht so viel tolles neues Zeug. Die hätten ruhig mal die Standard-Library aufräumen können, vermodertes Zeug raus und eklige Sachen neuschreiben (das email-Modul z.B. oder die ganzen Sachen mit Camelcase) und so Zeug wie die Unittest-Library erweitern (z.B. hinsichtlich Test-Preconditions).

Naja, ich geh mal ins Bett. Gute Nacht :)
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Man kann den Django Leuten dies nicht vorhalten. PEP 3333 ist zwar "quasi" akzeptiert aber bis auf wsgiref gibt es keine Implementation und PEP 444 ist noch weit von einer Lösung entfernt. Python 3.x hat desweiteren immer noch so seine Probleme mit unicode/bytes handling in der stdlib die jetzt mit 3.2 und 3.3 so langsam behoben werden.

Dann gibt es einige da daran interessiert sind 2.x mit PyPy weiterzuführen...

Nicht zu vergessen dass Django im Business Bereich viele Nutzer hat die RHEL nutzen und damit können die jetzt erstmal überhaupt anfangen darüber nachzudenken 2.4 Unterstützung aufzugeben. Solange man 2.4 unterstützen muss ist ein 3.x Port unwahrscheinlich.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Python 2.X fortzusetzen wäre das schlimmste was Python passieren kann. Aber Python 3.X im Netz ist auch noch keine Lösung.

Ich wünsche mir PIL als Py3 Port und eine Lösung für WSGI. Werkzeug und Jinja2 laufen zumindest experimentell auf Py3.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Also Werkzeug läuft garantiert (noch) nicht auf Python 3 weil es dafür gar keinen akzeptierten WSGI Standard gibt und ehrlich gesagt tendiert die Nachfrage auch gegen Null.

Was so schlimm daran wäre 2.x fortzusetzen sehe ich ehrlich gesagt nicht. 3.x hat beim "aufräumen" versagt, die Sprache ist zwar besser aber die stdlib ist zu grossen Teilen genauso schlecht wie vorher und man hat immernoch Inkonsistenzen wie built-in Klassen die nicht PEP 8 entsprechen.
lunar

Mein Gott, als gäbe es keine größeren Probleme als builtins, die nicht PEP 8 entsprechen ... :roll:

Man darf die Standardbibliothek gerne kritisieren, und sie hat Kritik weiß Gott oft genug nötig. Dennoch scheint sie wohl trotzdem gut genug für die tägliche Arbeit zu sein, denn seltsamerweise sind immer alle schnell mit Kritik bei der Hand, doch einen Entwurf für eine alternative Standardbibliothek hat noch niemand vorgestellt.

Ich persönlich halte die gegenwärtige Standardbibliothek jedenfalls tatsächlich für gut genug. Sie bietet all jene Module, die eine Standardbibliothek enthalten sollte, weil sie zu klein sind für eine externe Abhängigkeit (e.g. "os", "functools", "itertools", usw.), und genügend Module, um ein kleineres Skript auch mal ohne Abhängigkeiten zu schreiben. In größeren Anwendungen, die eh Abhängigkeiten haben, kann man dann ja bessere Drittmodule nutzen, zumal Python mit "virtualenv" und "pip" mittlerweile auch brauchbare Lösungen zur Verwaltung von Abhängigkeiten besitzt. Anstatt also an der Standardbibliothek herumzumäkeln, wäre es sinnvoller, Lösungen für tatsächliche, immanente Probleme von CPython zu erarbeiten (e.g. GIL).

Eine alternative Standardbibliothek würde eh über kurz oder lang ähnliche Probleme haben, denn es lässt sich bei großen Bibliotheken mit langen Release-Zyklen nur schwerlich vermeiden, dass einzelne Teile veralten. Auch wäre so oder so nicht jeder zufrieden mit der neuen Standardbibliothek. Dieses Phänomen lässt sich an nahezu jeder Standardbibliothek beobachten, die Standardbibliotheken vieler Sprachen werden durch beliebte Drittbibliothek ersetzt oder zumindest erweitert, oder sind in Teilen fehlerhaft oder zumindest verbesserungsbedürftig. Selbst Haskell hat Fehler in der Standardbibliothek (e.g. die Unterstützung regulärer Ausdrücke, oder in älteren Versionen die Unicode-Unterstützung).

Insofern wäre es schon schön, wenn Python 3 sich früher oder später durchsetzen würde, denn wie gesagt, die Sprache selbst wurde in Python 3 durchaus verbessert. Insbesondere die strikte Trennung zwischen Bytes und Zeichenketten ist eine sehr vernünftige und sinnvolle Änderung. Zumal ja auch die Standardbibliothek ein wenig bereinigt wurde (e.g. die Zusammenführung der urllib-Module).
Benutzeravatar
hendrikS
User
Beiträge: 420
Registriert: Mittwoch 24. Dezember 2008, 22:44
Wohnort: Leipzig

lunar hat geschrieben:Selbst Haskell hat Fehler in der Standardbibliothek (e.g. die Unterstützung regulärer Ausdrücke, oder in älteren Versionen die Unicode-Unterstützung).
Also ich meine das Fehlen von Features ist per se noch kein Fehler. Ich kenne nur einen Fehler (denke zumindest, daß es einer ist). Beim logarithmieren von seeeehr großen Zahlen kommt irgendein Käse raus, was in Python kein Problem ist. Bsp.:

Code: Alles auswählen

log (10^1000)
lunar hat geschrieben:die Sprache selbst wurde in Python 3 durchaus verbessert.
Ich (vielleicht auch andere) wäre durchaus interessiert, wenn jemand der Py3 Verfechter mal aufschreibt, was sich denn nun wirklich verbessert und nicht nur geändert hat. Was mich insbesondere bewegen sollte, die Nachteile, die Py3 mitsichbringt, (aus meiner Sicht Performance und Codekompatibilität) in Kauf zu nehmen.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

hendrikS hat geschrieben:
lunar hat geschrieben:Selbst Haskell hat Fehler in der Standardbibliothek (e.g. die Unterstützung regulärer Ausdrücke, oder in älteren Versionen die Unicode-Unterstützung).
Also ich meine das Fehlen von Features ist per se noch kein Fehler. Ich kenne nur einen Fehler (denke zumindest, daß es einer ist).
Unicode-Unterstützung ist doch wohl 2011 kein Feature mehr.
BlackJack

@hendrikS: Ich mache ja auch einen weiten Bogen um Python 3, aber ich finde da gibt es durchaus Verbesserungen. Unicode vs. Bytes, wobei die Probleme die sich dadurch in diversen Modulen der Standardbibliothek auftun, so langsam wohl behoben werden. `print()` als Funktion, "echte" Division, weniger Fehleranfällige ``except``-Syntax, New-Style-Klassen als Default, kein `input()` mehr.
lunar

@hendrikS: Ich muss DasIch zustimmen: Im Jahre des Herren 2011 ist Unicode kein "Feature" mehr, sondern obligatorisch. Insofern ist es durchaus blöd, wenn weder Text.Regex.Posix noch Text.Regex.PCRE vernünftig mit Unicode umgehen können. Statt Text.Regex.Posix kann man zwar Text.Regex.TDFA nutzen, aber für PCREs gibt es keine Alternative.

Zu den Verbesserungen von Python 3 hat BlackJack ja bereits das Wichtigste gesagt.
Benutzeravatar
/me
User
Beiträge: 3561
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

lunar hat geschrieben:Zu den Verbesserungen von Python 3 hat BlackJack ja bereits das Wichtigste gesagt.
Meine aktuellen Programme unter Python 2 enthalten jetzt schon immer folgenden Header:

Code: Alles auswählen

from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
Damit habe ich dann schon mal ein paar elementare Dinge von Python 3 abgefrühstückt. Jetzt fehlt mir nur noch die aufgeräumtere Standardbibliothek, aber die gibt es dann wirklich erst mit dem Umstieg auf Python 3. Vorher hätte ich allerdings gerne Django (+ WSGI) in der passenden Version.
lunar

"absolute_import" ist sicherlich auch noch empfehlenswert.
Benutzeravatar
/me
User
Beiträge: 3561
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

lunar hat geschrieben:"absolute_import" ist sicherlich auch noch empfehlenswert.
Das habe ich nur versehentlich nicht mitkopiert. Ist das bei 2.7 eigentlich schon Standard?
derdon
User
Beiträge: 1316
Registriert: Freitag 24. Oktober 2008, 14:32

Noch etwas, das interessant sein könnte: http://docs.python.org/library/future_builtins.html
Antworten