Warum zögern die Leute, Python 3 zu verwenden?

Python 3 wurde im Dezember 2008 veröffentlicht. Seitdem ist viel Zeit vergangen, aber noch heute zögern viele Entwickler, Python 3 zu verwenden. Selbst beliebte Frameworks wie Django sind noch nicht mit Python 3 kompatibel, verlassen sich aber immer noch auf Python 2.

Sicher, Python 3 weist einige Inkompatibilitäten mit Python 2 auf, und einige Benutzer müssen sich auf die Abwärtskompatibilität verlassen. Aber gibt es Python 3 nicht schon lange genug, damit die meisten Projekte Python 3 wechseln oder damit beginnen können?

Zwei konkurrierende Versionen zu haben, hat so viele Nachteile; Zwei Zweige müssen gepflegt werden, Verwirrung für die Lernenden und so weiter. Warum gibt es in der gesamten Python-Community so viele Bedenken, auf Python 3 umzusteigen?

Beachten Sie, dass ich diese Antwort nicht mehr aktualisiere. Ich habe auf meiner persönlichen Website unter http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html viel mehr Fragen und Antworten zu Python 3

Vorherige Antwort:

(Statusaktualisierung, September 2012)

Wir (dh die Python-Kernentwickler) haben bei der Veröffentlichung von Python 3.0 vorausgesagt, dass es ungefähr 5 Jahre dauern würde, bis 3.x die "Standard" -Option für neue Projekte gegenüber der 2.x-Serie wird. Diese Vorhersage ist der Grund, warum der geplante Wartungszeitraum für die Version 2.7 so lang ist.

Die ursprüngliche Version von Python 3.0 hatte auch einige kritische Probleme mit schlechter E / A-Leistung, die es für die meisten praktischen Zwecke praktisch unbrauchbar machten. Daher ist es sinnvoller, die Zeitleiste ab der Veröffentlichung von Python 3.1 Ende Juni 2009 zu starten E / A-Leistungsprobleme sind auch der Grund, warum es keine 3.0.z-Wartungsversionen gibt: Es gibt keinen guten Grund, warum sich jemand für ein Upgrade auf 3.1 auf 3.0 entscheiden sollte.

Zum Zeitpunkt des Redaktionsschlusses (September 2012) bedeutet dies, dass wir uns derzeit etwas mehr als drei Jahre im Übergangsprozess befinden und dass die Prognose weiterhin auf Kurs zu sein scheint.

Während die Menschen die Eingabe einer Python - 3 - Code werden die meisten regelmäßig wie von syntaktischen Änderungen gebissen printwerden eine Funktion, dass eigentlich kein Aufwand für Bibliothek Portierung ist , weil die automatisierte 2to3Umwandlung Werkzeug , um es ganz glücklich behandelt.

Das größte Problem in der Praxis ist tatsächlich ein semantisches: In Python 3 können Sie nicht so schnell und locker mit Textcodierungen spielen wie in Python 2. Dies ist sowohl der größte Vorteil gegenüber Python 2 als auch die größte Hürde bei der Portierung: Sie müssen die Probleme bei der Unicode-Verarbeitung beheben , damit ein Port ordnungsgemäß funktioniert (während in 2.x viele dieser Codes im Hintergrund falsche Daten mit erzeugten) Nicht-ASCII-Eingaben, die den Eindruck erwecken, zu arbeiten, insbesondere in Umgebungen, in denen Nicht-ASCII-Daten selten sind).

Sogar die Standardbibliothek in Python 3.0 und 3.1 hatte noch Probleme mit der Unicode-Verarbeitung, was es schwierig machte, viele Bibliotheken zu portieren (insbesondere solche, die sich auf Webdienste beziehen).

3.2 behandelte viele dieser Probleme und bot Bibliotheken und Frameworks wie Django ein viel besseres Ziel. 3.2 brachte auch die erste funktionierende Version von wsgiref(der Hauptstandard für die Kommunikation zwischen Webservern und in Python geschriebenen Webanwendungen) für 3.x, die eine notwendige Voraussetzung für die Übernahme in den Webspace war.

Key Abhängigkeiten wie NumPy und SciPy haben jetzt portiert, Installation und Abhängigkeitsmanagement - Tools wie zc.buildout, pipund virtualenvfür 3.x zur Verfügung stehen, unterstützt die Pyramide 1.3 Release Python 3.2, die kommende Django 1.5 Release experimentelle Python 3 Unterstützung umfasst, und die Freisetzung von 12,0 Das Twisted-Networking-Framework hat die Unterstützung von Python 2.5 eingestellt, um den Weg für die Erstellung einer Python 3-kompatiblen Version zu ebnen.

Zusätzlich zu den Fortschritten bei den Python 3-Kompatibilitätsbibliotheken und -Frameworks arbeitet die beliebte, mit JIT kompilierte PyPy-Interpreter-Implementierung aktiv an der Python 3-Unterstützung.

Die Tools zur Verwaltung des Migrationsprozesses wurden ebenfalls deutlich verbessert. Zusätzlich zu dem 2to3Tool, das im Rahmen von CPython bereitgestellt wird (das jetzt als am besten geeignet für einmalige Konvertierungen von Anwendungen angesehen wird, die keine Unterstützung für die 2.x-Serie benötigen), gibt es auch ein Tool python-modernize, das die 2to3Infrastruktur als Ziel verwendet Die (große) gemeinsame Teilmenge von Python 2 und Python 3. Dieses Tool erstellt eine einzige Codebasis, die mit Hilfe der sixKompatibilitätsbibliothek sowohl auf Python 2.6+ als auch auf Python 3.2+ ausgeführt werden kann . Die Python - Version 3.3 beseitigt auch eine der Hauptursachen für „Rauschen“ der vorhandenen Unicode - fähige Anwendungen migrieren: Python 3.3 noch einmal den ‚u‘ Präfix für Stringliterale unterstützt (es eigentlich nicht tunalles in Python 3 - es ist nur versehentlich zu vermeiden restauriert machen zu Python 3 Migration schwieriger für Benutzer, die bereits korrekt ausgezeichnet hatten ihren Text und binäre Literale in Python 2).

Wir sind also ziemlich zufrieden mit dem Fortschritt der Dinge - es sind noch fast zwei Jahre bis zu unserem ursprünglichen Zeitrahmen vergangen, und die Veränderungen ziehen sich gut durch das gesamte Python-Ökosystem.

Da viele Projekte ihre Python-Paketindex-Metadaten nicht ordnungsgemäß kuratieren und einige Projekte mit weniger aktiven Betreuern die Python 3-Unterstützung hinzugefügt haben, geben rein automatisierte PyPI-Scanner immer noch eine zu negative Sicht auf den Status der Python 3-Bibliothek Unterstützung.

Eine bevorzugte Alternative zum Abrufen von Informationen zum Python 3-Support unter PyPI ist http://py3ksupport.appspot.com/.

Diese Liste wird von Brett Cannon (einem langjährigen Python-Kernentwickler) persönlich kuratiert, um falsche Projektmetadaten, Python 3-Unterstützung, die sich in Tools zur Versionskontrolle, aber noch nicht in einer offiziellen Version befindet, und Projekte mit aktuelleren Gabeln zu berücksichtigen oder Alternativen, die Python 3 unterstützen. In vielen Fällen fehlen den Bibliotheken, die noch nicht in Python 3 verfügbar sind, Schlüsselabhängigkeiten und / oder die fehlende Python 3-Unterstützung in anderen Projekten verringert die Benutzeranforderung (z. B. wenn das Django-Kernframework in verfügbar ist) Mit Python 3, verwandten Tools wie South und Django-Sellerie, wird eher Python 3-Unterstützung hinzugefügt, und die Verfügbarkeit von Python 3-Unterstützung in Pyramid und Django erhöht die Wahrscheinlichkeit, dass Python 3-Unterstützung in anderen Tools wie gevent implementiert wird.

Die Website unter http://getpython3.com/ enthält einige hervorragende Links zu Büchern und anderen Ressourcen für Python 3, zeigt einige wichtige Bibliotheken und Frameworks auf, die Python 3 bereits unterstützen, und bietet Informationen dazu, wie Entwickler finanzielle Unterstützung von der anfordern können PSF beim Portieren von Schlüsselprojekten nach Python 3.

Eine weitere gute Ressource ist die Community-Wiki-Seite zu Faktoren, die bei der Auswahl einer Python-Version für ein neues Projekt zu berücksichtigen sind: http://wiki.python.org/moin/Python2orPython3

Ich glaube, dass ein Großteil des Zögerns auf zwei Dinge zurückzuführen ist:

• Wenn es nicht kaputt ist, reparieren Sie es nicht
• [XYZ-Bibliothek], die wir benötigen, hat keinen 3.0-Port

Es gibt einige Unterschiede im Verhalten der Kernsprache, die in diesem Dokument beschrieben werden . Etwas so Einfaches wie das Ändern von "print" von einer Anweisung in eine Funktion wird beispielsweise eine Menge Python 2.x-Code beschädigen - und das ist nur das Einfachste. Sie haben die älteren Klassen in 3.0 komplett abgeschafft. Tatsächlich handelt es sich um ganz andere Sprachen - daher ist das Portieren von altem Code nicht so einfach, wie manche vielleicht annehmen.

Es gibt keine zwingenden Gründe für bestehende Unternehmen, Zeit, Geld und Mühe in die Migration zu investieren, ohne die vorhandenen Funktionen zu ändern. Ich möchte damit sagen, dass Code, der auf Python 2 basiert, seit langer Zeit im Geschäft läuft, stabil, getestet und mit allen aktuellen Produktfeatures ausgestattet ist. Warum sollte jemand Zeit, Geld und Mühe aufwenden, um Python 3 nur für die Migration zu verschieben?

Abgesehen davon, dass nach der Migration sichergestellt wird, dass keine Regressionsfehler auftreten und dass all diese Kopfschmerzen unvermeidbar sind.

Für neue Projekte ist die Richtlinie schlicht und einfach. Alles beginnt mit den folgenden Punkten:

1. Liefert irgendeine Distribution wie Ubuntu Python 3 in ihrer Standardinstallation?
2. Was ist das Bibliotheksökosystem für Python 3?
3. Sind alle Frameworks ua kompatibel mit Python 3. usw. usw.

Es ist Ihr üblicher Prozess, eine neue Sprache zu wählen. Hier kommt das Hühnerei-Problem ins Spiel. Nicht viele Leute benutzen es, weil nicht viele Leute es benutzen. Letztendlich hat niemand Lust, sich überhaupt zu bewegen.

Die Rückwärtskompatibilität zu brechen war noch nie eine gute Sache. Am Ende endet immer ein guter Prozentsatz der Benutzer.

Ungefähr zu der Zeit, als Python 2.0 veröffentlicht wurde, wurde Python immer beliebter. Es gab viele neue Benutzer, die natürlich die neueste Version verwendeten, da sie keine Abhängigkeiten von den älteren Versionen hatten. Da viele Leute standardmäßig 2.0 verwenden, war der Druck auf Bibliotheksentwickler usw. groß.

Zum Zeitpunkt der Veröffentlichung von Python 3.0 gab es bereits eine große Anzahl von Benutzern, die von Python 2.0 abhängig waren, und ein exponentielles Wachstum (das einen konstanten Faktor im Vergleich zu bestehenden Benutzern darstellt) kann offensichtlich nicht auf unbestimmte Zeit aufrechterhalten werden.

Persönlich schienen die neuen Funktionen in den Tagen von Python 2 viel überzeugender zu sein als die von Python 3.

Früher dachte ich, Python 3 würde irgendwann sowieso die Kontrolle übernehmen, aber jetzt bin ich mir nicht so sicher. Aber es ist nicht nur Python, das dieses Problem hat. Immerhin, wie viele Leute verwenden Perl 6 ehrlich? Das ist schon ein bisschen länger als in Python 3, IIRC.

Ein großer Show Stopper ist für mich die Integer Division. Ich habe wissenschaftliche Codes, die darauf beruhen, dass x / 2 x abgerundet ergibt (wenn x eine Ganzzahl ist).

Python 3 würde das nicht tun, aber eine .5-Antwort geben (für ungerade x).
Ich kann nicht einfach alles / in meinem Code durch // ersetzen, weil ich manchmal Float-Division mache und daher das Float-Verhalten will.

Damit ich auf Python 3 portieren kann, muss ich Zehntausende von Codezeilen durchforsten, jedes / prüfen und sehen, ob ich herausfinden kann, ob es / oder // sein sollte.

Python 3 ist schön, um ein neues Projekt zu starten, wenn alle Bibliotheken, die Sie benötigen, bereits auf Py3k portiert sind.

Wenn dies nicht möglich ist, ist die Verwendung von Python 2.7 das Beste aus beiden Welten: Sie haben fast jede Bibliothek für Python 2.x erstellt und können Ihren Code schrittweise so ändern, dass er Py3k-kompatibel ist, sodass die Migration bei Bedarf einfach ist es. Die Liste der Syntax-Goodies von Py3k, die Sie bereits in 2.7 haben, ist ziemlich lang. Vergessen Sie nur nicht, aus zu importieren __future__. Meine Favoriten sind standardmäßig Unicode und Division erzeugt immer einen Float.

Aus Sicht der Webdienste: Keines der wichtigsten Server-Frameworks oder Web-Frameworks unterstützt Python3.

Update: Offensichtlich war dies Anfang 2011 der Fall, ab sofort (Ende 2013) arbeiten die meisten wichtigen Frameworks mit Python3. Einige sind jedoch immer noch nicht kompatibel. Ein wichtiges Beispiel wäre Twisted, wo noch gearbeitet wird .

Es gibt keine zwingenden Gründe, warum ich P3K verwendet habe, es sei denn, Sie erledigen schwere i18n-Arbeiten. In meinen Streifzügen habe ich festgestellt, dass der allgegenwärtige Unicode ein Hindernis für meine (ASCII-) Arbeit darstellt und die Generatoren, die meinen Code blockieren müssen.

In ein paar Jahren wird 3 ein zwingenderes Umfeld bieten, aber nicht heute.

Distributionen stellen Python3 nicht zur Verfügung. Es gibt einige Randdistros, die Python2 bereits verlassen. Mainstream-Linux-Varianten wie Debian, Ubuntu usw. tun dies jedoch nicht. Das ist der Hauptgrund für mich als Anwendungsautor, es auch nicht zu tun.

Obwohl ich den Übergang vorbereitet und sogar versucht habe, die inkompatiblen Syntaxkonstrukte zu vermeiden , kann ich ihn nicht richtig testen. Es läuft wirklich auf das Henne-Ei-Problem hinaus.