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 print
devenir une fonction, ce n’est pas un problème pour le portage d’une bibliothèque, car l’ 2to3
outil 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
, pip
et virtualenv
sont 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' 2to3
outil 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-modernize
qui utilise l' 2to3
infrastructure 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 six
bibliothè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