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.