Il fallait bien s’y mettre un jour. Dans un an Python 3 sera probablement assez mûr et répandu pour envisager un switch. Du coup j’ai changé mon modèle de fichier Python vide, il ressemble dorénavant à ceci :
#!/usr/bin/env python # -*- coding: utf-8 -*- # vim: ai ts=4 sts=4 et sw=4 nu from __future__ import (unicode_literals, absolute_import, division, print_function) |
Tous mes nouveaux modules Python avait déjà par défaut les 3 premières (exécutable sous Unix, encodé en UTF8 et avec une indentation de 4 espaces sous VI). En prime maintenant :
- Toutes les chaînes sont automatiquement de l’unicode.
- Les imports sont absolus par défaut. Il faut forcer l’import relatif.
- La division ne tronque pas. Pour obtenir l’ancien comportement, il faut utiliser
//. print()est forcé d’être une fonction (snif).
Je me dédinausorise petit à petit.
Salut les mecs!
Je ne me suis pas encore penché sur Python 3…est-ce que vous connaissez un bon tuto (synthétique et simple) sur Python 3, ses nouveautés et la migration 2.7>3 ?
Merci pour vos articles toujours aussi intéressants!
L’intérêt principal du print, c’est que maintenant ça passe dans les lambda (sans passer par sys.jesaisplusquoi), c’est parfois pratique.
Perso je rajoute :
Et quelques import de librairies que j’utilise presque à chaque fois. C’est rapide à supprimer si je ne le veux pas, et chiant à taper quand j’en ai besoin. C’est clair que pour du web ça sert à rien, par contre.
@Syl: Pour moi la référence est http://python3porting.com/bookindex.html (en anglais). C’est très complet tout en restant bien accessible.
Si tu utilises 2.7 et que tu fais l’import présenté ici, tu as déjà fait une bonne partie du boulot.
dans un an tu jettes ton fichier avec tous tes imports parce que t’es passe a python 3?
@syl + @kontre: pas mieux.
@foxmask: pas sûr. Mais c’est le but. Après je doute franchement que tout code 2.7 aura disparu dans un an. Les sites Web codés cette années vont pas être réécris l’année prochaine pour Python 3, et seuls quelques aventuriers écrivent des site Web en Python 3. Mais il faut transitionner petit à petit. Je pense aussi à porter 0bin en Python 3, mais rien ne presse.
Y’a également cet article d’Armin Ronacher (Flask, Werkzeug , Jinja2…) qui est pas mal :)
Porting to Python 3 Redux : http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
Quand tu développes des libs aujourd’hui, c’est une grave erreur de pas prévoir une compatibilité python3 :p
Je préfère ne pas utiliser __future__.unicode_literals, mais ne supportent que Python 3.3, qui a encore u”.
Si je dois utiliser Python 3.2, je vais utiliser les u() et b() de six. https://pypi.python.org/pypi/six
Question à la con : est si on développe tout en Python 3 (choix que j’ai fait car j’étais le seul à utiliser mon code quand j’ai commencé), faut-il penser à backporter vers la branche 2 ?
Y’a t-il encore un intérêt ?
@Lennart : Je pense que le ré-introduction de u”” dans python3.3 est là juste pour facilité la migration de vieux code mais en aucun cas ne change le comportement de python3, à savoir : unicode par défaut.
Honnêtement je pense qu’aujourd’hui il faut commencer à développer pour Python3 avec une rétrocompatibilité que développer pour python2 en essayant de faire marcher son code pour python3.
@Luigi : Y’a beaucoup de gens qui sont contraint de rester encore pas mal de temps sur python2, donc si ton code s’adresse à eux, c’est vivement recommandé.
Je vous conseille le module “tox” pour tester votre code sur différentes version de python ;-)