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

221

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?

Ham Vocke
quelle
3
Gibt es wirklich so viele neue Projekte, die mit Python 2 beginnen? Oder sind es nur alteingesessene Projekte wie Django?
Carson63000
3
Können Sie einige der Diskussionen / Quellen zitieren?
Michael Easter
12
@ Michael Ostern - Er muss nicht. Überprüfen Sie einfach das Python-Tag auf SO; Viele Leute dort oben sind der Meinung, dass "Learn 2.x, 3.x noch nicht fertig ist".
Turm
5
Haben Sie die Python 3 Wall of Shame noch nicht gesehen ?
Detly
7
@detly, es heißt jetzt Python 3 Wall of Superpower
freeforall tousez

Antworten:

249

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

ncoghlan
quelle
3
Basierend auf den Fortschritten der letzten 18 Monate aktualisiert (und ausdrücklich darauf hingewiesen, dass 3.1 aufgrund der miserablen IO-Leistung in 3.0 das erste produktionsfähige 3.x-Release war)
ncoghlan
1
Bis zu einem gewissen Grad (dh wir wussten, dass es in 2.6 deutlich langsamer ist als das io-Subsystem), aber die Auswirkungen auf die allgemeine Benutzerfreundlichkeit waren weitaus schlimmer als erwartet (unsere IO-Benchmarks haben sich seitdem merklich verbessert, so dass es keine Chance gibt, dass es so etwas gibt) Versand heute)
ncoghlan
6
Der vorgeschlagene Zeitrahmen scheint jetzt im Jahr 2015 nicht so enthusiastisch zu sein: |
Zetah
1
Die Art und Weise, wie ich es sehe (und ich werde dafür auf dem Spiel stehen), ist, dass an der Codierungsfront Py3 den Zen of Python in dem Punkt "Pragmatismus schlägt Reinheit" verletzt (und tut dies auch nach wie vor) : Py3 ist verschlüsselungsrein. Py2 war codier-pragmatisch.
Jürgen A. Erhard
2
Py3 ist immer noch pragmatisch in Bezug auf Codierungen (ansonsten hätten wir kein Ersatzszenario). Wir begegnen nur vielen * nix-Benutzern, die nicht daran interessiert sind, zu erfahren, wie Betriebssystemoberflächen auf Plattformen wie Windows, .NET und JVM funktionieren ( einschließlich Android). Ich habe mehr darüber auf developerblog.redhat.com/2014/09/09/… geschrieben. Die Hauptauswirkung war, dass "Fehler nicht unbemerkt passieren sollten", da wir datenabhängige Fehler, die Mojibake erzeugten, in Strukturtypfehler verwandelt haben Beschwerde über das Mischen von Binärdaten und Textdaten.
ncoghlan
48

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.

TZHX
quelle
2
Das Problem der Abhängigkeit ohne Port ist ebenfalls rekursiv. Was benötigt wird, ist für weit verbreitete Bibliotheken, die wenige oder keine Abhängigkeiten außerhalb der stdlib zu port haben, was dann eine Kettenreaktion auslösen kann.
Tony Meyer
10
Ich würde die Reihenfolge ändern. Viele von uns gehen auf und ab und warten darauf, dass ein bestimmtes Paket auf den 3.
S.Lott
1
@ Tony - aus diesem Grund finde ich es ein großer Segen für 3.0, dass Numpy jetzt dafür verfügbar ist. @ S.lott - ich denke es kommt wirklich darauf an, ob 3 etwas bietet was du willst. Um ehrlich zu sein, bin ich erst vor kurzem von 2.5 auf 2.7 umgezogen - ich gehöre also nicht wirklich zu den Leuten, die dem "Neuesten und Größten" folgen.
TZHX
1
Es 2to3ist jedoch auch nicht so schwierig, alten Code mit Hilfe von zu portieren, wie manche befürchten.
ncoghlan
5
Es hilft nicht, dass so gut wie jedes Betriebssystem, das Python in die Distribution einbindet (OSX, Linux usw.), immer noch auf einer alten Version von Python 2 steckt. Warum für Python 3 schreiben, wenn niemand Ihren Code verwenden kann, ohne herumzuspielen mit den Interna ihres Betriebssystems?
Ant
28

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.

kamaal
quelle
14

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.

Steve314
quelle
3
Zur Hölle, ich benutze immer noch Fortran77. :) Und die meisten echten "Funktionen" von Python 3 wurden in 2.6 und 2.7 ohne so viele Kompatibilitätsprobleme zurückportiert. Das einzige, was Python 3 wirklich bietet, ist eine "sauberere" Syntax.
TZHX
3
Der Vergleich von Python 3 und Perl 6 ist falsch. Python 3 ist ein inkrementeller Sprung von Python 2, während Perl 6 ein grundlegendes Redesign darstellt. Perl 5 und Perl 6 sind Schwestersprachen und werden noch lange zusammen existieren. Auf der anderen Seite plant Python 3, Python 2 zu ersetzen und nicht nur nebeneinander zu existieren. Das ist ein großer Unterschied.
kamaal
1
Perl 6 befindet sich noch in der Entwicklung. Ja, Rakudo Perl ist die Implementierung, die der Perl 6-Spezifikation am nächsten kommt, implementiert aber noch nicht alles. Es gibt einfach noch keine produktionsbereite Perl 6-Implementierung.
Htbaa
1
@Htbaa für viele Definitionen von Vollständigkeit und Bereitschaft. Perl 6 ist vollständig und produktionsbereit. Die Sache ist, dass es eine Weile dauern kann, bis die vollständige Spezifikation erreicht ist. Es gibt ähnliche Dinge auch für andere Sprachen. Zum Beispiel entsprach GCC bis vor kurzem nicht ganz der gesamten C ++ - Spezifikation. Das Entwerfen und Implementieren von Sprachen ist ein sehr langsamer Prozess.
kamaal
1
rakudo.org/node/75 Rakudo Star wurde vor langer Zeit veröffentlicht. Sie müssen es versuchen.
kamaal
11

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.

Sharky
quelle
7
Die Option "-Q" (2.2 bis 2.7) kann Warnungen für die Division auslösen . Außerdem verwendet fixdiv.py diese Warnungen, um die Ausdrücke in Ihren Skripten zu aktualisieren.
Eryk Sun
10

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.

9000
quelle
10

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 .

vartec
quelle
Übrigens hat Django gerade damit begonnen, Python3 in Version 1.5 experimentell zu unterstützen.
21.01.13,
1
Django 1.6 unterstützt nun offiziell Python 3. Flask unterstützt es auch.
Chhantyal
8

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.

Paul Nathan
quelle
4

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.

Mario
quelle
4
Dies mag einmal zutreffen, aber "apt-get install python3" und "yum install python3" haben beide lange funktioniert. Tools wie Tox und Dienste wie Shining Panda CI erleichtern das Testen über mehrere Python-Versionen hinweg.
ncoghlan
Jetzt installieren viele dieser Distributionen im Gegensatz zu vielen anderen Programmiersprachen standardmäßig python3.
Antti Haapala