Pourquoi les gens hésitent-ils à utiliser Python 3?

Python 3 est sorti en décembre 2008. Beaucoup de temps s’est écoulé depuis, mais de nombreux développeurs hésitent encore à utiliser Python 3. Même les frameworks populaires tels que Django ne sont pas encore compatibles avec Python 3 mais reposent toujours sur Python 2.

Bien sûr, Python 3 présente des incompatibilités avec Python 2 et certaines personnes doivent s’appuyer sur la compatibilité ascendante. Mais Python 3 n’a-t-il pas assez longtemps été utilisé pour que la plupart des projets changent ou commencent avec Python 3?

Avoir deux versions concurrentes présente de nombreux inconvénients. deux branches doivent être maintenues, confusion pour les apprenants, etc. Alors, pourquoi la communauté Python hésite-t-elle tellement à passer à Python 3?

Notez que je ne mets plus à jour cette réponse. J'ai un Q & R Python 3 beaucoup plus long sur mon site personnel à l' adresse http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Réponse précédente:

(Mise à jour, septembre 2012)

Lors de la publication de Python 3.0, nous (les développeurs centraux de Python) avions prédit qu'il faudrait environ 5 ans à la version 3.x pour devenir le choix "par défaut" des nouveaux projets de la série 2.x. Cette prévision explique pourquoi la période de maintenance planifiée pour la version 2.7 est si longue.

La version originale de Python 3.0 présentait également des problèmes critiques liés à de mauvaises performances d’IO, qui la rendaient inutilisable pour la plupart des tâches pratiques. Il est donc plus logique de commencer la chronologie de la publication de Python 3.1 à la fin de juin 2009. Les problèmes de performances IO sont également la raison pour laquelle il n'y a pas de versions de maintenance de la version 3.0.z: il n'y a pas de bonne raison que quiconque veuille rester avec la version 3.0 au lieu de la mise à niveau vers la version 3.1).

Au moment de la rédaction de cet article (septembre 2012), cela signifie que le processus de transition est un peu plus de trois ans et que cette prévision semble toujours être sur la bonne voie.

Bien que les personnes qui saisissent du code Python 3 soient le plus souvent confrontées à des modifications syntaxiques telles que le fait de printdevenir une fonction, ce n’est pas un problème pour le portage d’une bibliothèque, car l’ 2to3outil de conversion automatique le gère très facilement.

Le problème le plus important dans la pratique est en réalité un problème sémantique: Python 3 ne vous permet pas de jouer rapidement et librement avec des encodages de texte comme le fait Python 2. C’est à la fois son principal avantage par rapport à Python 2, mais également l’obstacle majeur au portage: vous devez résoudre vos problèmes de gestion Unicode pour que le port fonctionne correctement entrées non-ASCII, donnant l’impression de travailler, en particulier dans des environnements où les données non-ASCII sont peu communes).

Même la bibliothèque standard de Python 3.0 et 3.1 avait toujours des problèmes de gestion Unicode, ce qui rendait difficile le portage de nombreuses bibliothèques (en particulier celles liées aux services Web).

3.2 a résolu un grand nombre de ces problèmes, fournissant une cible bien meilleure pour les bibliothèques et les frameworks tels que Django. 3.2 a également apporté la première version de travail wsgiref(la norme principale utilisée pour la communication entre les serveurs Web et les applications Web écrites en Python) pour 3.x, ce qui était une condition préalable nécessaire à l’adoption dans l’espace Web.

Dépendances clés comme NumPy et SciPy ont maintenant été portés, l' installation et des outils de gestion de la dépendance aiment zc.buildout, pipet virtualenvsont disponibles pour 3.x, la version 1.3 prend en charge Pyramide Python 3.2, la prochaine version de Django 1.5 inclut le support Python 3 expérimental, et la libération de 12,0 la structure de réseau Twisted a cessé de prendre en charge Python 2.5 afin de permettre la création d’une version compatible avec Python 3.

Outre les avancées sur les bibliothèques et les infrastructures de compatibilité Python 3, l'implémentation populaire de l'interpréteur PyPy compilé par JIT travaille activement sur la prise en charge de Python 3.

Les outils de gestion du processus de migration se sont également nettement améliorés. Outre l' 2to3outil fourni dans le cadre de CPython (qui est maintenant considéré comme étant le mieux adapté aux conversions ponctuelles d'applications qui ne nécessitent pas de prise en charge de la série 2.x), il existe également une infrastructure python-modernizequi utilise l' 2to3infrastructure pour cibler le (grand) sous-ensemble commun de Python 2 et Python 3. Cet outil crée une base de code unique qui s'exécutera à la fois sur Python 2.6+ et Python 3.2+ à l'aide de la sixbibliothèque de compatibilité. La version 3.3 de Python élimine également l'une des principales causes de "bruit" lors de la migration d'applications Unicode existantes: Python 3.3 prend à nouveau en charge le préfixe 'u' pour les littéraux de chaîne (ce n'est pas le castout ce qui se trouve dans Python 3 - il vient d’être restauré pour éviter de rendre par inadvertance la migration vers Python 3 plus difficile pour les utilisateurs qui avaient déjà correctement distingué leurs textes et leurs littéraux binaires dans Python 2).

Nous sommes donc plutôt satisfaits de l’évolution de la situation: il reste encore près de deux ans dans notre calendrier initial et les changements se répercutent bien dans l’ensemble de l’écosystème Python.

Étant donné que de nombreux projets ne définissent pas correctement leurs métadonnées d'index de package Python et que certains projets avec des mainteneurs moins actifs ont été poussés à ajouter du support Python 3, les scanners PyPI purement automatisés donnent toujours une image trop négative de l'état de la bibliothèque Python 3. soutien.

Une alternative privilégiée pour obtenir des informations sur le niveau de prise en charge de Python 3 sur PyPI est http://py3ksupport.appspot.com/.

Cette liste est personnellement préparée par Brett Cannon (un développeur de longue date du développeur principal de Python) afin de prendre en compte les métadonnées de projet incorrectes, la prise en charge de Python 3 figurant dans les outils de contrôle de code source mais pas encore dans une version officielle, ainsi que les projets contenant des fourchettes plus récentes. ou des alternatives prenant en charge Python 3. Dans de nombreux cas, les bibliothèques qui ne sont pas encore disponibles sur Python 3 manquent de dépendances clés et / ou le manque de prise en charge de Python 3 dans d’autres projets réduit la demande des utilisateurs (par exemple, une fois que le framework Django principal est disponible). Python 3, des outils apparentés tels que South et django-celery ont davantage de chances d’ajouter la prise en charge de Python 3, et la disponibilité de cette prise en charge dans Pyramid et Django augmente les chances que la prise en charge de Python 3 soit implémentée dans d’autres outils tels que gevent).

Le site http://getpython3.com/ inclut d'excellents liens vers des livres et d'autres ressources pour Python 3, identifie certaines bibliothèques et infrastructures clés qui prennent déjà en charge Python 3 et fournit également des informations sur la manière dont les développeurs peuvent demander une aide financière à la société. PSF dans le portage de projets clés vers Python 3.

Une autre bonne ressource est la page wiki de la communauté sur les facteurs à prendre en compte lors du choix d'une version Python pour un nouveau projet: http://wiki.python.org/moin/Python2orPython3

Je crois que beaucoup d'hésitation vient de deux choses:

• Si ce n'est pas cassé, ne le répare pas
• [Bibliothèque XYZ] dont nous avons besoin ne possède pas de port 3.0

Il existe de nombreuses différences dans le comportement de la langue de base, décrites dans ce document . Quelque chose d'aussi simple que de changer "print" d'une instruction en une fonction, par exemple, va casser beaucoup de code Python 2.x - et ce n'est que le plus simple. Ils se sont complètement débarrassés des classes de style ancien dans la version 3.0. En fait, il s’agit de langues très différentes. Le portage de code ancien n’est donc pas aussi simple que certains pourraient le croire.

Il n’existe aucune raison contraignante pour les entreprises existantes de passer du temps, de l’argent et des efforts pour migrer vers quelque chose sans changer l’ensemble des fonctionnalités existantes. Je veux dire, la base de code sur la série Python 2 est opérationnelle depuis longtemps, stable, testée et possède toutes les fonctionnalités actuelles du produit. Pourquoi quelqu'un dépenserait-il du temps, de l'argent et des efforts pour déplacer Python 3 dans le seul but d'y migrer?

En plus de la post-migration, il n’ya pas d’échec de la régression et tout ce que la migraine est inévitable

Pour les nouveaux projets, la politique est claire et simple, tout commence par les points suivants:

1. Est-ce qu'une distribution comme Ubuntu intègre Python 3 dans son installation par défaut?
2. Quel est l'écosystème de la bibliothèque pour Python 3.
3. Tous les frameworks et al sont-ils compatibles avec Python 3. etc etc.

C'est votre processus habituel de "choix d'une nouvelle langue". C’est là que le problème de l’œuf de poule entre en jeu. Peu de gens l’utilisent parce que peu de gens l’utilisent. En fin de compte, personne n’a envie de le faire.

Rompre la compatibilité avec les versions antérieures n’a jamais été une bonne chose. À la fin, vous finissez toujours avec un bon pourcentage d’utilisateurs.

À l'époque de la sortie de Python 2.0, la popularité de Python augmentait rapidement. Beaucoup de nouveaux utilisateurs ont naturellement utilisé la dernière version, car ils ne dépendaient pas des anciennes versions. Avec beaucoup de gens adoptant 2.0 par défaut, il y avait beaucoup de pression sur les développeurs de bibliothèques, etc.

Au moment de la sortie de Python 3.0, un grand nombre d’utilisateurs dépendaient déjà de Python 2.0 et la croissance exponentielle (maintien d’un facteur constant par rapport aux utilisateurs existants) ne pouvait évidemment pas être maintenue indéfiniment.

Personnellement, les nouvelles fonctionnalités de Python 2 semblaient bien plus convaincantes que celles fournies par Python 3.

Je pensais que Python 3 finirait par prendre le relais de toute façon, mais je n'en suis pas si sûr maintenant. Mais il n’ya pas que Python qui a ce problème. Après tout, combien de personnes utilisent honnêtement Perl 6? Cela fait un peu plus longtemps que Python 3, IIRC.

Un grand obstacle pour moi, qui, selon moi, ne peut pas être résolu par la traduction automatique, est la division entière. J'ai des codes scientifiques qui s'appuient sur x / 2 donnant x arrondi à la baisse (lorsque x est un entier).

Python 3 ne ferait pas cela, mais donnerait une réponse .5 (pour x impair).
Je ne peux pas simplement remplacer tout / dans mon code par // car parfois je divise en flottant, et je veux donc le comportement de flottant.

Donc, pour pouvoir porter en python 3, je vais devoir parcourir des dizaines de milliers de lignes de code, en vérifiant tous les / et en vérifiant si je peux déterminer s'il convient ou non.

Python 3 permet de démarrer un nouveau projet si toutes les bibliothèques dont vous avez besoin sont déjà portées sur Py3k.

Si ce n'est pas une option, utiliser Python 2.7 est le meilleur des deux mondes: vous avez presque toutes les bibliothèques créées pour Python 2.x et vous pouvez modifier progressivement votre code pour qu'il soit compatible avec Py3k, de sorte que la migration soit facile lorsque vous décidez de le faire. il. La liste des goodies syntaxiques de Py3k que vous avez déjà dans la version 2.7 est plutôt longue. N'oubliez pas d'importer depuis __future__. Mes favoris sont Unicode par défaut et la division produit toujours un float.

Du point de vue des services Web: Python3 n’est pris en charge par aucun des principaux environnements de serveur ni des environnements Web.

Mise à jour: il est évident que c'était le cas au début de 2011 et qu'à partir de maintenant (fin 2013), la plupart des principaux cadres fonctionnent avec Python3. Cependant, certains ne sont toujours pas compatibles. Un exemple significatif serait Twisted, où le travail est toujours en cours .

Il n’existe aucune raison impérieuse d’utiliser P3K à moins que vous ne travailliez beaucoup. Au cours de mes incursions, j'ai trouvé que le Unicode omniprésent était un obstacle à mon travail (ASCII) et que les générateurs obligatoires pour obstruer mon code.

Dans quelques années, 3 présentera un environnement plus attrayant, mais pas aujourd'hui.

Les distributions ne rendent pas Python3 disponible. Il existe certaines distributions marginales qui font déjà la transition entre Python2 et Python2. Mais les variantes Linux classiques telles que Debian, Ubuntu, etc. ne le font pas. C'est la raison principale pour moi en tant qu'auteur d'application de ne pas faire non plus.

Bien que j'ai préparé la transition et même essayé d'éviter les constructions syntaxiques incompatibles , je ne peux pas le tester correctement. Cela revient vraiment au problème de la poule et de l'œuf.