Welche Version von Python (2.4, 2.5, 2.6, 3.0) Sie standardisieren Sie für die Produktion Entwicklungsanstrengungen auf (und warum)?

Question

In unserer Gruppe, die wir tun, in erster Linie Engine-Architektur und Inhalte der Integrationsarbeit suchen und die meisten dieser Codebasis sind in Python. Alle unsere Build-Tools und Python-Modul Abhängigkeiten sind in der Quellcodeverwaltung, damit sie überprüft werden und die Umwelt belastet für den Einsatz unabhängig von O / Plattform, ein bisschen ähnlich den Ansatz virtualenv verwendet.

Seit Jahren haben wir eine Code-Basis kompatibel mit Python 2.3 beibehalten, da eine der kommerziellen Produkte, die wir auf Python hängt 2.3 verwenden. Im Laufe der Jahre hat sich diese mehr und mehr Probleme verursacht als neuere Tools und Bibliotheken neueren Versionen von Python benötigen seit 2.3 ~ 2004 herauskam.

Wir haben vor kurzem unsere entkoppelte Bauumgebung von Abhängigkeiten von der Umgebung des kommerziellen Produkts und eine beliebige Version von Python verwenden können (oder Java) wir wollen. Es ist schon über einen Monat oder so, da wir auf Python 2.6 als die neueste Version von Python standardisierten, die rückwärts mit früheren Versionen kompatibel ist.

Python 3.0 ist keine Option (bis jetzt), da wir unsere Code-Basis zu viel wandern müssten unsere Build-und Integrations-Tools zu arbeiten, wieder richtig zu machen.

Wir mögen viele der neuen Features von Python 2.6, vor allem die verbesserten Module und Dinge wie Klasse Dekorateure, aber viele Module hängen wir die Python 2.6 Interpreter auf Grund verschiedener Abschreibungs Warnungen Auslauf. Ein weiteres Werkzeug, das wir interessiert sind, in EC2 Cloud-Cluster-Knoten für die Verwaltung, Betreuer nicht einmal Arbeit richtig mit Python 2.6.

Jetzt frage ich mich, ob wir auf Python 2.5 jetzt anstelle von Python 2.6 in der Entwicklung von Produktionsumgebung Werkzeugen standardisieren sollen. Die meisten der Werkzeuge, die wir wollen / müssen scheinen korrekt mit Python 2.5 zu arbeiten. Wir versuchen, dies jetzt zu klären, bevor es gibt viele Abhängigkeiten von Python 2.6-Funktionen oder Modulen.

Vielen Dank!

-Michael

Answer 1

würde ich nicht 2.6 nur wegen deprecation Warnungen verlassen; diese werden im Laufe der Zeit verschwinden. (Sie können die -W ignore Option, um die Python-Interpreter nutzen sie, um zu verhindern ausgedruckt werden, zumindest), aber wenn Module müssen Sie eigentlich verwenden, funktioniert nicht mit Python 2.6, das ein berechtigter Grund mit 2,5 bleiben würde. Python 2.5 ist weit verbreitet jetzt und wahrscheinlich wird für eine lange Zeit zu kommen (man denkt an, wie lange 2.3 gedauert hat!), Also auch wenn Sie mit 2.5 gehen, werden Sie nicht für eine Weile aktualisieren gezwungen werden.

Ich verwende Python 2.5 für all meine Entwicklungsarbeit, aber nur, weil es ist die Version, die in Gentoo (Linux) 's-Paket-Repository verfügbar sein geschieht. Wenn die Gentoo-Maintainer Python 2.6 „stabil“ * erklären, werde ich zu, dass wechseln. Natürlich wäre diese Argumentation nicht unbedingt auf Sie zutreffen.

* Python 2.6 tatsächlich stabil ist, der Grund, warum es nicht als solche in Gentoo erklärt, dass Gentoo auf andere Programme stützt, die sich auf Python abhängig sind und noch nicht aufgerüstet mit 2,6 zu arbeiten. Auch diese Argumentation wahrscheinlich nicht für Sie gilt.

Answer 2

Meine Firma ist in 2.5 standardisiert. Genau wie Sie können wir nicht den Schalter auf 3,0 für eine Million Gründe, aber ich sehr viel wollen wir bis 2,6 bewegen konnte.

Ihr Tag zu Tag Codierung werde ich durch die Dokumentation zu suchen und ich werde genau das Modul oder eine Funktion, die ich will, aber dann wird es die kleine Anmerkung haben: Neu in der Version 2.6

würde ich mit der neuesten Version gehen sagen, und wenn Sie Abschreibungs Warnungen haben Pop-up (es wahrscheinlich nur sehr wenige sein), dann in einem gehen Sie einfach einen besseren Weg finden, es zu tun. Insgesamt Ihr Code wird mit 2,6 besser sein.

Answer 3

Für mich ist das wichtigste mit Python zu halten 2.5+ ist, weil es offiziell ctypes unterstützt, die viele Plug-Systeme geändert.

Auch wenn Sie ctypes arbeiten mit 2.3 / 2.4 finden können, sind sie nicht offiziell gebündelt.

Also mein Vorschlag 2.5 wäre.

Answer 4

Wir bleiben mit 2.5.2 für jetzt. Unsere Tech-Stack-Zentren auf Django (aber wir haben ein Dutzend anderen Kleinkram.) Also wir bleiben in der Nähe zu dem, was sie tun.

Wir mussten zurück zu docutils bis 0,4 gehen, damit es funktionieren würde, mit epydoc 3.0.1. Bisher hat dies kein großes Problem gewesen, aber es kann - irgendwann -. Uns dazu bringen, unsere Verwendung von epydoc zu überdenken

Das 2.6 Upgrade ist Teil unseres Entwicklungsplanes. Wir haben Budget, aber nicht jetzt festen Zeitplan.

Das 3.0-Upgrade, ähnlich, ist etwas, das ich Leute daran erinnern. Wir haben für sie Budget. Wir tun es nicht in diesem Jahr, es sei denn Django 3.0 springt. Wir könnten es im nächsten Jahr tun.

Answer 5

Ich denke, die beste Lösung, um die Hoffnung auf dem Gesamt Gleichförmigkeit aufgeben, obwohl eine gemeinsame Umgebung mit etwas zu streben ist. Sie werden immer mit der Version Problemen konfrontiert werden, zum Beispiel wenn sie auf die nächstbeste Interpreter Version zu aktualisieren.

Also anstatt auf einer Basis Umgang mit ihm pro Ausgabe dieses Problem, indem sie einen guten Blick auf Ihrem Release-Management lösen könnte.

Stattdessen Quelle der Freigabe, geht je nach Plattform-Binärdateien (neben der Source-Distribution).

Also, was Sie tun, ist, dass Sie eine Anzahl der unterstützten CPUs, zum Beispiel definieren: x86-32, x86-64, Sparc

Dann, welche Betriebssysteme: Linux, Windows, Solaris, FreeBSD

Für jede OS Sie eine Reihe ihrer Hauptversionen unterstützen.

Der nächste Schritt ist, dass Sie Binärdateien für alle von ihnen bieten.

Ja in der Tat erfordert dies einige ziemlich Infrastrukturinvestitionen und aus automatischen Gebäude aus Repositories Einstellung (Sie sie haben?).

Die Vorteile bestehen darin, dass die Benutzer nur ‚ein‘ Ding haben zu installieren und Sie können leicht Versionen wechseln oder auch Mischvarianten. Eigentlich kann man auch verschiedene Programmiersprachen mit diesem Ansatz verwenden, ohne Ihr Release-Management zu beeinflussen zu viel.