Angenommen, ich habe ein in Python geschriebenes Allzweck-Dienstprogramm für Endbenutzer entwickelt. Zuvor hatte ich nur eine Version verfügbar, die für Python später als Version 2.3 oder so geeignet war. Es war ausreichend zu sagen: "Lade Python herunter, wenn du es brauchst, dann führe dieses Skript aus". Es gab nur eine Version des Skripts in der Quellcodeverwaltung (ich verwende Git), um den Überblick zu behalten.
Bei Python 3 ist das nicht mehr unbedingt wahr. Für die absehbare Zukunft muss ich zwei verschiedene Versionen entwickeln, eine für Python 2.x und eine für Python 3.x. Aus Entwicklungsperspektive kann ich mir einige Optionen vorstellen:
Ich stehe derzeit auf Option 3, da die ersten beiden eine Menge fehleranfälliger Langeweile beinhalten würden. Aber Option 3 scheint chaotisch und mein Quellcode-Kontrollsystem sollte Patches für mich verwalten.
Für Distributionsverpackungen gibt es mehrere Optionen zur Auswahl:
Auch hier lehne ich mich derzeit für Option 3 an, obwohl ich noch nicht versucht habe, einen solchen Stubloader zu entwickeln.
Irgendwelche anderen Ideen?
Bearbeiten: Meine ursprüngliche Antwort basierte auf dem Stand von 2009, mit Python 2.6 und 3.0 als aktuellen Versionen. Nun gibt es mit Python 2.7 und 3.3 noch weitere Möglichkeiten. Insbesondere ist es jetzt durchaus möglich, eine einzige Codebasis für Python 2 und Python 3 zu verwenden.
Siehe Python 2-Code in Python 3 portieren
Ursprüngliche Antwort:
Die offizielle Empfehlung lautet:
Für die Portierung von bestehendem Python 2.5 oder 2.6 Quelltext zu Python 3.0, der beste Strategie ist die folgende:
(Voraussetzung :) Beginnen Sie mit einer exzellenten Testabdeckung.
Port zu Python 2.6. Dies sollte nicht mehr Arbeit als der durchschnittliche Port sein von Python 2.x zu Python 2. (x + 1). Stellen Sie sicher, dass alle Ihre Tests bestehen.
(Immer noch mit 2.6 :) Schalten Sie den Befehlszeilenschalter -3 ein. Das ermöglicht Warnungen über Funktionen, die sein werden entfernt (oder geändert) in 3.0. Führen Sie Ihre Testen Sie die Suite erneut und beheben Sie den Code Sie bekommen Warnungen, bis es da ist Keine Warnungen mehr und alle deine Tests noch übergeben.
Führen Sie den 2to3 Source-to-Source-Übersetzer über Ihren Quellcode-Baum aus. (Siehe 2 bis 3 - Automatisierte Python 2 bis 3 Code-Übersetzung für mehr dazu Werkzeug.) Führen Sie das Ergebnis der Übersetzung unter Python 3.0. Manuell behebt alle verbleibenden Probleme, behebend Probleme, bis alle Tests wieder bestanden haben.
Es wird nicht empfohlen zu versuchen zu schreiben Quelltext, der unter unverändert läuft Python 2.6 und 3.0; du müsstest Verwenden Sie einen sehr verzerrten Codierungsstil, z.B. Druckanweisungen vermeiden, Metaklassen und vieles mehr. Wenn du bist eine Bibliothek verwalten, die dies tun muss unterstützt sowohl Python 2.6 als auch Python 3.0, ist der beste Ansatz, Schritt 3 oben durch Bearbeiten der 2.6 zu ändern Version des Quellcodes und läuft der 2to3 Übersetzer wieder, anstatt Bearbeitung der Version 3.0 der Quelle Code.
Idealerweise erhalten Sie eine einzige Version, die mit 2.6 kompatibel ist und mit 2 to3 in 3.0 übersetzt werden kann. In der Praxis können Sie dieses Ziel möglicherweise nicht vollständig erreichen. Möglicherweise müssen Sie also einige manuelle Änderungen vornehmen, damit es unter 3.0 funktioniert.
Ich würde diese Änderungen in einem Zweig beibehalten, wie Ihre Option 2. Anstatt jedoch die finale 3.0-kompatible Version in diesem Zweig beizubehalten, würde ich erwägen, die manuellen Änderungen vor 2to3 anzuwenden Übersetzungen, und fügen Sie diesen modifizierten 2.6-Code in Ihre Branche ein. Der Vorteil dieser Methode wäre, dass der Unterschied zwischen diesem Zweig und dem 2.6-Stamm ziemlich klein wäre und nur aus manuellen Änderungen bestehen würde, nicht aus den von 2to3 vorgenommenen Änderungen. Auf diese Weise sollten die einzelnen Zweige leichter zu verwalten und zusammenzuführen sein, und Sie sollten von zukünftigen Verbesserungen in 2to3 profitieren können.
Alternativ können Sie auch ein bisschen abwarten. Fahren Sie mit Ihrer Portierung nur so weit fort, wie Sie mit einer einzelnen 2.6-Version plus 2-zu-3-Übersetzung arbeiten können, und verschieben Sie die verbleibenden manuellen Änderungen, bis Sie wirklich eine 3.0-Version benötigen. Vielleicht brauchst du zu diesem Zeitpunkt keine manuellen Verbesserungen mehr ...
Für die Entwicklung ist Option 3 zu umständlich. Das Aufrechterhalten von zwei Zweigen ist der einfachste Weg, obwohl die Art, dies zu tun, zwischen VCSen variieren wird. Viele DVCS werden mit getrennten Repos glücklicher sein (mit einer gemeinsamen Abstammung, um das Zusammenführen zu unterstützen), und zentralisiertes VCS wird wahrscheinlich einfacher mit zwei Zweigen arbeiten. Option 1 ist möglich, aber Sie können etwas vermischen und eine etwas fehleranfälligere IMO verpassen.
Für die Verteilung würde ich, wenn möglich, auch Option 3 verwenden. Alle 3 Optionen sind trotzdem gültig und ich habe von Zeit zu Zeit Variationen dieser Modelle gesehen.
Ich glaube nicht, dass ich diesen Weg überhaupt gehen würde. Es ist schmerzhaft, egal wie man es betrachtet. Wirklich, es sei denn, es besteht ein starkes kommerzielles Interesse daran, beide Versionen gleichzeitig zu behalten, dies ist mehr Kopfschmerzen als Gewinn.
Ich denke, es macht mehr Sinn, für 2.x zumindest für ein paar Monate, bis zu einem Jahr, weiter zu entwickeln. Zu einem bestimmten Zeitpunkt ist es an der Zeit, eine endgültige, stabile Version für 2.x zu deklarieren und die nächsten für 3.x +
zu entwickelnZum Beispiel werde ich nicht zu 3.x wechseln, bis einige der wichtigsten Frameworks auf diese Weise gehen: PyQt, matplotlib, numpy und einige andere. Und es macht mir nichts aus, wenn sie irgendwann die 2.x-Unterstützung einstellen und einfach anfangen, 3.x zu entwickeln, weil ich weiß, dass ich in kurzer Zeit auch zu 3.x wechseln kann / p>
Ich würde mit der Migration auf 2.6 beginnen, was sehr nah an Python 3.0 liegt. Vielleicht möchten Sie sogar auf 2.7 warten, was noch näher an Python 3.0 liegt.
Und dann, nachdem Sie auf 2.6 (oder 2.7) migriert haben, schlage ich vor, dass Sie nur eine Version des Skripts behalten, mit Dingen wie "if PY3K: ... else: ..." an den seltenen Orten, wo es wird obligatorisch sein. Natürlich ist es nicht die Art von Code, die wir Entwickler gerne schreiben, aber dann müssen Sie sich keine Gedanken über die Verwaltung mehrerer Skripte oder Zweige oder Patches oder Distributionen machen, was ein Alptraum wird.
Was auch immer Sie wählen, stellen Sie sicher, dass Sie gründliche Tests mit 100% Codeabdeckung haben.
Viel Glück!
Welche Option auch immer für die Entwicklung gewählt wird, die meisten potenziellen Probleme könnten durch gründliche Komponententests gemildert werden, um sicherzustellen, dass die beiden Versionen eine übereinstimmende Ausgabe erzeugen. Allerdings scheint mir Option 2 am natürlichsten zu sein: Änderungen von einem Quellbaum auf einen anderen Quellbaum anzuwenden, ist eine Aufgabe, für die die meisten Versionskontrollsysteme entwickelt wurden - warum sollten Sie nicht die Vorteile der Tools nutzen, die diese bieten?
Für die Entwicklung ist es schwierig zu sagen, ohne "Ihr Publikum zu kennen". Power Python-Benutzer würden wahrscheinlich schätzen, dass sie nicht zwei Kopien Ihrer Software herunterladen müssen, aber für eine allgemeinere Benutzerbasis sollte es wahrscheinlich "einfach funktionieren".
Tags und Links python python-3.x version-control