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


221

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?


3
Existe-t-il vraiment autant de nouveaux projets utilisant Python 2? Ou est-ce juste des projets établis de longue date comme Django?
Carson63000

3
Pouvez-vous citer certaines des discussions / sources?
Michael Easter

12
@ Michael Easter - Il n'a pas à le faire. Il suffit de vérifier la balise python sur SO; beaucoup de gens là-haut sont de l'avis "apprendre 2.x, 3.x n'est pas encore prêt".
Rook

5
N'as-tu pas vu le mur de honte Python 3 ?
Détly

7
@detly, c'est maintenant appeler le mur de superpuissance Python 3
gratuit tous all

Réponses:


249

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


3
Mise à jour sur la base des progrès réalisés au cours des 18 derniers mois (et a explicitement noté le fait que 3.1 était la première version 3.x viable en production, en raison des performances IO catastrophiques de la version 3.0)
ncoghlan le

1
Dans une certaine mesure (c’est-à-dire que nous savions qu’il était nettement plus lent que le sous-système io dans la version 2.6), l’impact sur la facilité d’utilisation en général a été bien pire que prévu (nos valeurs de référence en matière d’OI se sont nettement améliorées depuis. expédié aujourd'hui)
ncoghlan

6
Le calendrier proposé ne semble pas si enthousiaste en 2015: |
Zetah

1
La façon dont je vois les choses (et je vais être brûlé par certains pour cela) est que, sur le front de l'encodage, Py3 a violé (et continue comme ça) le zen de Python dans le point "le pragmatisme bat la pureté" : Py3 est un codage pur. Py2 était codant-pragmatique.
Jürgen A. Erhard

2
Py3 est toujours pragmatique à propos des encodages (sinon, nous n’aurions pas de substitution), nous rencontrons beaucoup d’utilisateurs * nix qui ne sont pas intéressés par le fonctionnement des interfaces du système d’exploitation sur des plates-formes telles que Windows, .NET et JVM ( y compris Android). J'en ai écrit plus à ce sujet sur developerblog.redhat.com/2014/09/09/…. L'impact principal a été sur le front "les erreurs ne doivent pas passer silencieusement", car nous avons modifié les bogues liés aux données qui ont produit mojibake en erreurs de type structurel. se plaindre de mélanger des données binaires et textuelles.
ncoghlan

48

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.


2
Le problème de dépendance n'a pas de port est également récursif. Ce qui est nécessaire, c'est que les bibliothèques largement utilisées qui ont peu ou pas de dépendances en dehors de stdlib à mettre en communication puissent démarrer une réaction en chaîne.
Tony Meyer

10
Je changerais l'ordre. Nous sommes nombreux à faire les cent pas, attendant qu'un paquet particulier migre vers 3.
S.Lott

1
@ Tony - c'est pourquoi je pense que le fait que Numpy soit maintenant disponible pour la version 3.0 est une aubaine. @ S.Lott - Je suppose que cela dépend vraiment du fait que 3 offre quelque chose que vous voulez. Pour être honnête, je n’ai que très récemment passé de 2,5 à 2,7 - je ne suis donc pas vraiment de ceux qui suivent les «derniers et meilleurs».
TZHX

1
Porter du vieux code avec l'aide de 2to3n'est pas aussi difficile que certaines personnes le craignent, cependant.
ncoghlan

5
Cela n'aide pas que presque tous les systèmes d'exploitation qui incluent Python dans la distribution (OSX, Linux, etc.) soient toujours bloqués sur une version ancienne de Python 2. Pourquoi écrire pour Python 3 alors que personne ne peut utiliser votre code sans se moquer de avec les internes de leur système d'exploitation?
Ant

28

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.


14

À 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.


3
Bon sang, j'utilise toujours Fortran77. :) Et la plupart des vraies "fonctionnalités" de Python 3 ont été rétroportées en 2.6 et 2.7, sans autant de problèmes de compatibilité. La seule chose que Python 3 offre réellement est une syntaxe "plus propre".
TZHX

3
Comparer Python 3 et Perl 6 est faux. Python 3 est un saut incrémental de Python 2 alors que Perl 6 est une refonte totale. Perl 5 et Perl 6 sont des langues sœurs et continueront à coexister pendant longtemps. D'autre part, Python 3 prévoit de remplacer Python 2, et pas seulement coexister. C'est une grande différence.
Kamaal

1
Perl 6 est encore en développement. Oui, Rakudo Perl est l’implémentation la plus proche de la spécification Perl 6 mais n’implémente pas encore tout. Il n’existe pas encore de mise en œuvre Perl 6 prête pour la production.
Htbaa

1
@Htbaa pour de nombreuses définitions de complétude et de préparation. Perl 6 est terminé et prêt pour la production. Le fait est que cela peut prendre un certain temps pour correspondre à la spécification complète, il y a des choses similaires avec d'autres langues. Par exemple, jusqu'à récemment, GCC ne correspondait pas vraiment à l'ensemble de la spécification C ++. La conception et la mise en œuvre du langage est un processus très lent.
Kamaal

1
rakudo.org/node/75 La star de Rakudo est sortie depuis longtemps. Vous devez l'essayer.
Kamaal

11

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.


7
L' option "-Q" (2.2 à 2.7) peut déclencher des avertissements pour la division. De plus, fixdiv.py utilise ces avertissements pour mettre à jour les expressions dans vos scripts.
Eryk dim

10

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.


10

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 .


En passant, Django vient de commencer à supporter expérimentalement Python3, dans la version 1.5.
9000

1
Django 1.6 prend maintenant officiellement en charge Python 3. Flask le prend également en charge.
Chhantyal

8

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.


4

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.


4
Cela a peut-être été vrai une fois, mais "apt-get install python3" et "yum install python3" fonctionnent tous les deux depuis longtemps. Des outils tels que tox et des services tels que Shining Panda CI facilitent les tests sur plusieurs versions de Python.
ncoghlan

Maintenant, beaucoup de ces distributions installent python3 par défaut, contrairement à beaucoup d'autres langages de programmation.
Antti Haapala
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.