Änderungen von Python 2 zu 3 machen Code-Refactoring unumgänglich

Die Aussicht, sich mit altem Code auseinandersetzen zu müssen, um ihn mit einer neuen Sprachversion zum Laufen zu bringen, gehört zu den Dingen, die Entwickler um jeden Preis vermeiden wollen. Es ist schwer, alten Code zu verstehen; unerwartete Änderungen könnten neue Fehler einführen, die Leistung wird wahrscheinlich beeinträchtigt, und es ist ein enormer Aufwand für wenig Ertrag. Schließlich fügen Sie nichts Neues hinzu, sondern sorgen nur dafür, dass der Code wie zuvor läuft. Dieser Beitrag behandelt einige Beispiele für Änderungen in Python 2 und 3, die ein Refactoring des Codes unumgänglich machen.

Ihre Python-2-Anwendung läuft also genau wie vorgesehen. Sie funktioniert nun schon seit einigen Jahren perfekt, das Entwicklungsteam hat alle Macken ausgebügelt, und alle sind mit ihrer Leistung zufrieden. Sie erledigt ihre Aufgabe und ist aus dem Weg, wenn sie nicht mehr gebraucht wird.

Doch plötzlich wird eine neue Sicherheitslücke veröffentlicht, die Python 2 betrifft. Sicherheitspatches sind nicht mehr verfügbar, da die offizielle Unterstützung für diese Version eingestellt wurde. Ihre fantastische Anwendung ist nun ohne eigenes Verschulden ebenfalls verwundbar und stellt eine Sicherheitslücke für das Unternehmen dar. Als gewissenhafter IT-Manager beauftragen Sie Ihr Entwicklungsteam, den Code vorrangig so umzugestalten, dass er mit einer sicheren Version von Python 3 läuft.

Ihr Team hatte andere Projekte in der Hand, und all das wird nun auf Eis gelegt. Es ist eine kostspielige Entscheidung, aber es muss getan werden, oder? Es dauert einige Wochen, um alle Details über die notwendigen Codeänderungen und deren Auswirkungen auf andere, unerwartete oder nicht mehr in Erinnerung gebliebene Abschnitte des Codes zu erfassen. Ein großer Teil der Kernlogik muss neu geschrieben werden, da einige Funktionen seit Python 2 veraltet sind und die Ersetzung in Python 3 nicht einfach so erfolgen kann.

Wieder vergehen ein paar Wochen, in denen die Entwickler damit zu kämpfen haben, schlecht dokumentierten Code zu verstehen, der von einem ehemaligen Kollegen geschrieben wurde, der nicht mehr im Unternehmen ist. Es scheint einige Abschnitte des Codes zu geben, die "einfach funktionieren", aber niemand versteht mehr, warum. Oh, und ein paar Abhängigkeiten unterstützen Python 3 nicht und werden es wahrscheinlich auch in nächster Zeit nicht tun - die Projekte scheinen nicht mehr unterstützt zu werden.

Nach Monaten harter Arbeit kehrt das Entwicklungsteam mit einem Frankenstein-Build einer neuen Version der Anwendung zurück. Sie ähnelt dem Original nur geringfügig; einige Entscheidungen in Bezug auf die Benutzeroberfläche machen es schwierig, das gesammelte Wissen zu nutzen, so dass eine Umschulung der Anwender erforderlich ist.

Die Leistung scheint jedes Mal zu leiden, wenn jemand eine Änderung an der Datenbank vornimmt. Niemand weiß genau, warum, aber eine der Abhängigkeiten, die von Grund auf neu geschrieben werden musste, hat das besser gelöst. Und alle Projekte, die das Team ursprünglich in Angriff genommen hatte, sind nun ebenfalls in Verzug und über dem Budget.

Das Team nahm einige der Ergebnisse mit, um sie als nützliches Wissen für künftige Refactoring-Bemühungen aufzubewahren:

Abteilung:

Python 3: 5/2 == 2,5

Python 2: 5/2 == 2 (die Verdoppelung von "/" zu "//" ergibt das alte Verhalten)

Die Division ganzer Zahlen ergibt jetzt einen Float und ist nicht mehr ein Int.

Drucken:

Python 3: print("")

Python 2: print ""

Wörterbuchänderungen:

Python 3: dict-Methoden keys(), items(), values() geben Views zurück

Python 2: Diese Methoden geben Listen zurück. Außerdem werden die Methoden iterkeys(), iteritems und itervalues() nicht mehr unterstützt.

Sortierung:

Python 3: cmp() sollte nicht mehr verwendet werden.

Text und binär:

Text- und Binärdaten sind nun unterschiedliche Konzepte und sollten nicht mehr in Zeichenketten gespeichert werden. Einige String-Operationen funktionieren nicht mehr in Daten, in denen sie vorher funktionierten, weil sie Zeichen enthalten, die in Strings nicht mehr zulässig sind. 

 

Tupel:

Tupel-Parameter können nicht mehr wie bisher entpackt werden.

Mehrere Schlüsselwörter wurden entfernt:

“<>” is now “!=”.

Ganzzahlige Literale funktionieren nicht mehr mit einem schließenden l oder L.

String-Literale funktionieren nicht mehr mit einem schließenden u oder U.

Der Import aller Daten aus einem Modul funktioniert jetzt nur noch auf Modulebene, nicht mehr innerhalb einer Funktion.

Und viele, viele andere Änderungen (Die vollständige Liste kann hier eingesehen werden: https://docs.python.org/3/whatsnew/3.0.html, die als Quelle für diesen Artikel verwendet wurde).

Am Ende des Prozesses funktionierte die Anwendung schlechter als zuvor; die Umstellung auf ein neues Sprachniveau brachte keinen wirklichen Nutzen - es wurden nur Konstrukte verwendet, die alte Funktionen ersetzten, und keine neuen fortgeschrittenen Funktionen, da das Ziel nur darin bestand, die Anwendung wieder zum Laufen zu bringen. Es handelte sich um eine kostspielige Aufgabe, die sich auf viele andere Aktivitäten im Unternehmen auswirkte und Störungen auf allen Ebenen verursachte.

Was hätte man stattdessen tun können?

Eine bessere Alternative gibt es in Form des Extended Lifecycle Support für Python. Durch die rechtzeitige Bereitstellung von Sicherheitskorrekturen ohne Änderungen auf Sprachebene hätte das Problem einfach durch die Bereitstellung des Dienstes gelöst werden können. Der gleiche Code wäre weiterhin wie bisher ausgeführt worden, die Sicherheitslücke wäre behoben worden, und alle anderen Störungen hätten vollständig vermieden werden können.