|
1234567891011121314151617181920212223242526272829303132333435363738394041 |
- title: Python 3 et __future__
- slug: python3-future
- date: 2013-01-01
- chapo: 2013 sera l'année de Python 3
-
- **2013 sera l'année de Python 3,** en tout cas je ferai tout ce que je peux pour que mes programmes/bibliothèques soient compatibles et je compte bien avoir des projets utilisant uniquement cette version, il est temps d'avancer. Je pensais être contraint d'utiliser *[2to3](http://docs.python.org/3/library/2to3.html)* ou *[six](http://pypi.python.org/pypi/six/)* mais ça ne me permettait pas d'y aller en douceur, jusqu'à ce que [Mathieu tweete](https://twitter.com/magopian/status/285308957021597699) une solution que je trouve élégante, [l'utilisation de \_\_future__](http://stackful.io/blog/quick-tips-on-making-your-code-python-3-ready/) permet en un seul import de vous préparer à Python 3 :
-
- #!python
- from __future__ import (print_function, division,
- absolute_import, unicode_literals)
-
- ce qui permet ensuite d'utiliser `print` comme une fonction dans votre code :
-
- #!python
- >>> print("Cool!")
- Cool!
-
- de faire des division d'`integer` qui ne renvoient pas zéro :
-
- #!python
- >>> 5/7
- 0.7142857142857143
-
- de faire des imports relatifs de manière explicite :
-
- #!python
- >>> from . import awesomeness
-
- et enfin, ce qui va permettre de vraiment avoir l'impression de coder en Python 3 et de prendre en compte ses spécificités relatives aux chaînes de caractères qui ont motivé la non comptabilité ascendante avec cette nouvelle version majeure du langage :
-
- #!python
- >>> "zOMG unicode by default"
- u"zOMG unicode by default"
-
- Utilisez explicitement le `b"string"` si vous souhaitez avoir le comportement par défaut à base de strings de Python 2.X. C'est un début, c'est insuffisant mais ça fait déjà avancer les choses en codant pour l'avenir tout en minimisant les contraintes associées.
-
- Puisqu'on parle de programmation, [Éric](http://n.survol.fr/n/if-less-programming) m'a fait découvrir la [if-less programmation](http://alisnic.github.com/posts/ifless/) :
-
- > It is obvious that we can’t avoid conditionals, especially when comparing primitive data types. But most of the time it is not considered a good practice to use ifs in a Object-Oriented language. So what is really wrong with conditionals in a Object Oriented language?
-
- Ce qui donne effectivement à réfléchir, surtout lorsque l'on utilise un langage comme Python qui donne une grande flexibilité à ce sujet.
|
