Quelle version de Python (2.4, 2.5, 2.6, 3.0) utilisez-vous pour les efforts de développement de la production (et pourquoi)?

Question

Dans notre groupe, nous nous occupons principalement de l’architecture des moteurs de recherche et de l’intégration de contenu, et la majeure partie de cette base de code est en Python. Tous nos outils de construction et les dépendances de modules Python sont dans le contrôle de code source. Ils peuvent donc être extraits et l'environnement chargé, quel que soit leur système d'exploitation, doit être similaire à l'approche virtualenv utilise.

Pendant des années, nous avons maintenu une base de code compatible avec Python 2.3, car l'un des produits commerciaux que nous utilisons dépend de Python 2.3. Au fil des ans, cela a posé de plus en plus de problèmes, car les nouveaux outils et bibliothèques ont besoin de nouvelles versions de Python depuis la sortie de la version 2.3 en 2004.

Nous avons récemment dissocié notre environnement de construction des dépendances de l'environnement du produit commercial et pouvons utiliser n'importe quelle version de Python (ou Java) de notre choix. Cela fait environ un mois depuis que nous avons normalisé Python 2.6 en tant que version la plus récente de Python, qui est rétrocompatible avec les versions précédentes.

Python 3.0 n’est pas une option (pour le moment) car nous devrions migrer une trop grande partie de notre base de code pour que nos outils de construction et d’intégration puissent fonctionner à nouveau correctement.

Nous apprécions nombre des nouvelles fonctionnalités de Python 2.6, en particulier les modules améliorés et des éléments tels que les décorateurs de classe, mais nombre de modules dont nous dépendons font que l’interpréteur Python 2.6 émet divers avertissements de dépréciation. Le Superviseur ne fonctionne même pas. correctement avec Python 2.6.

Maintenant, je me demande si nous devrions normaliser Python 2.5 pour le moment au lieu d’utiliser Python 2.6 dans le développement d’outils d’environnement de production. La plupart des outils que nous voulons / dont nous avons besoin semblent fonctionner correctement avec Python 2.5. Nous essayons de résoudre ce problème avant qu'il y ait beaucoup de dépendances sur les fonctionnalités ou les modules de Python 2.6.

Merci beaucoup!

-Michael

Answer 1

Je ne voudrais pas abandonner la version 2.6 uniquement à cause des avertissements de dépréciation; ceux-ci disparaîtront avec le temps. (Vous pouvez au moins utiliser l'option -W ignorer de l'interpréteur Python pour empêcher leur impression.) Mais si les modules que vous devez utiliser ne fonctionnent pas avec Python 2.6, ce serait une raison légitime de rester avec 2.5. Python 2.5 est largement utilisé maintenant et le restera probablement longtemps (pensez au temps passé par la version 2.3!), Donc même si vous utilisez la version 2.5, vous ne serez pas obligé de mettre à niveau pendant un certain temps.

J'utilise Python 2.5 pour tout mon travail de développement, mais uniquement parce que c'est la version disponible dans le référentiel de paquets de Gentoo (Linux). Lorsque les responsables Gentoo déclareront Python 2.6 "stable" * , je passerai à cela. Bien sûr, ce raisonnement ne s’appliquerait pas nécessairement à vous.

* Python 2.6 est stable, la raison pour laquelle Gentoo n’a pas été déclaré comme tel est que Gentoo repose sur d’autres programmes qui dépendent eux-mêmes de Python et ne sont pas encore mis à niveau pour fonctionner avec la version 2.6. Encore une fois, ce raisonnement ne vous concerne probablement pas.

Answer 2

Mon entreprise est normalisée en 2.5. Comme vous, nous ne pouvons pas passer à la version 3.0 pour un million de raisons, mais j'aimerais beaucoup pouvoir passer à la version 2.6.

En effectuant le codage au quotidien, je vais parcourir la documentation et trouver exactement le module ou la fonction que je souhaite, mais il comportera la petite annotation suivante: Nouveauté de la version 2.6

Je dirais qu'il faut utiliser la version la plus récente. Si des avertissements de dépréciation apparaissent (il y en aura probablement très peu), il vous suffit de rechercher une meilleure façon de le faire. Globalement, votre code sera meilleur avec 2.6.

Answer 3

Pour moi, le plus important est de rester avec Python 2.5+ car il supporte officiellement ctypes , ce qui a modifié de nombreux systèmes de plug-ins.

Bien que vous puissiez trouver des ctypes fonctionnant avec 2.3 / 2.4, ils ne sont pas officiellement regroupés.

Donc, ma suggestion serait 2.5.

Answer 4

Nous nous en tenons à la version 2.5.2 pour le moment. Notre pile technologique est centrée sur Django (mais nous en avons une douzaine d'autres.) Nous restons donc proches de ce qu'ils font.

Nous avons dû revenir à docutils à 0.4 pour que cela fonctionne avec epydoc 3.0.1. Jusqu'à présent, cela n'a pas été un gros problème, mais cela pourrait éventuellement nous amener à repenser notre utilisation d'epydoc.

La mise à niveau 2.6 fait partie de notre plan de développement. Nous avons un budget, mais pas d’horaire fixe pour le moment.

La mise à niveau 3.0, de la même manière, est quelque chose que je rappelle aux gens. Nous devons budgétiser pour cela. Nous ne le ferons cette année que si Django passe à 3.0. Nous pourrions le faire l'année prochaine.

Answer 5

Je pense que la meilleure solution consiste à renoncer à l'espoir d'une uniformité totale, même si un environnement commun est un objectif à atteindre. Vous serez toujours confronté à des problèmes de version, par exemple lors de la mise à niveau vers la meilleure version d'interprète suivante.

Ainsi, au lieu de traiter chaque problème par problème, vous pouvez résoudre ce problème en examinant attentivement votre gestion des versions.

Au lieu de publier le code source, privilégiez les fichiers binaires dépendant de la plate-forme (outre la distribution source).

Vous définissez donc un nombre de processeurs pris en charge, par exemple: x86-32, x86-64, sparc

Ensuite, quels systèmes d'exploitation: Linux, Windows, Solaris, FreeBSD

Pour chaque système d'exploitation, vous prenez en charge un certain nombre de leurs versions principales.

La prochaine étape consiste à fournir des fichiers binaires pour chacun d'entre eux.

Oui, cela nécessitera certes beaucoup d'investissements en infrastructure et la mise en place de bâtiments automatiques à partir de vos référentiels (vous les avez?).

L'avantage est que vos utilisateurs n'ont qu'une seule chose à installer et que vous pouvez facilement changer de version ou même mélanger des versions. En fait, vous pouvez même utiliser différents langages de programmation avec cette approche sans trop affecter votre gestion des versions.