davidbgk
/
larlet-fr-david

title:      Python : lisibilité vs simplicité
slug:       python-et-underscore
date:       2006-04-25 21:54:36
type:       post
vignette:   images/logos/python_nouveau.png
contextual_title1:  Bonnes pratiques et astuces Python
contextual_url1:    20080511-bonnes-pratiques-et-astuces-python
contextual_title2:  Benchmarks map, filter vs. list-comprehensions
contextual_url2:    20061025-benchmarks-map-filter-vs-list-comprehensions
contextual_title3:  Principales nouveautés dans Python 2.5
contextual_url3:    20060304-principales-nouveautes-dans-python-25

<p>Le programmeur est fainéant. C'est ainsi. S'il ne l'était pas, il n'essayerait pas de s'aider d'un ordinateur. Du coup il évite dans la mesure du possible de s'encombrer de variables trop longues, ou d'appels répétitifs un peu trop élaborés. Heureusement, en Python, on peut simplifier tout ça. Mais la simplification peut mener à un manque de lisibilité dans certains cas. Un cas intéressant est celui de l'underscore.</p>

<h2>La valeur précédente</h2>


<p>Pas grand monde ne le sait mais testez de vous-même dans un shell&nbsp;:</p>


<pre>&gt;&gt;&gt; 8 + 2
10
&gt;&gt;&gt; _
10</pre>


<p>C'est très peu employé et ça rend le code très peu lisible, quitte a avoir une variable temporaire rappelant la dernière valeur autant qu'on comprenne de quoi il retourne. Surtout qu'il est possible d'attribuer d'autres fonctions à l'underscore.</p>


<h2>Variable temporaire inutile</h2>


<p>L'underscore est souvent utilisé pour créer des listes de liste&nbsp;:</p>

<pre>&gt;&gt;&gt; [[0] for _ in range(3)]
[[0], [0], [0]]</pre>


<p>Vous vous demandez peut-être pourquoi ne pas faire un simple&nbsp;:</p>

<pre>&gt;&gt;&gt; [[0]] * 3</pre>


<p>Tout simplement car ça crée des copies de listes et non des nouvelles listes donc si vous en modifiez une, ça se répercute sur les autres.</p>


<p>Il peut être aussi utilisé pour des fonctions renvoyant trop d'information, par exemple dans&nbsp;:</p>


<pre>&gt;&gt;&gt; jour, mois, _ = date_actuelle()</pre>


<p>Si l'on ne veut pas s'encombrer de l'année (en supposant que le troisième argument renvoyé par la fonction est l'année bien sûr...).</p>


<p>Ces utilisations ponctuelles sont pratiques et ne nuisent pas trop à la lisibilité du code.</p>


<h2>Traduction avec gettext</h2>


<pre>import gettext
gettext.bindtextdomain('myapplication', '/path/to/my/language/directory')
gettext.textdomain('myapplication')
_ = gettext.gettext
# ...
print _('This is a translatable string.')</pre>


<p>Ça par contre c'est très employé, et oui les programmeurs sont des fainéants ;-). C'est pas forcément lisible et ça demande un peu d'habitude mais il faut reconnaître que c'est bien pratique et que c'est devenu usage courant donc autant l'utiliser.</p>


<h2>Utilisation à la place de self</h2>


<p>C'est souvent demandé à Guido sur la mailing-list python et il est assez intransigeant là-dessus (et je suis d'accord avec lui). Python est un langage simple et on doit pas tomber dans les gri-gri de Perl (désolé pour les mongeurs dans l'assistance...). Alors bien sûr vous <em>pouvez</em> utiliser n'importe quel mot-clé à la place de self pour vos classes et plus il est court moins vous aurez à taper de caractère ensuite mais <strong>self</strong> est un bon compromis, il est à la fois court et lisible. Pensez aux personnes qui vont devoir relire un jour votre code (il est très probable que ce soit vous et que vous ayez évolué !), autant se baser sur un formalisme commun (parce que ça commence comme ça puis on se met à utiliser <strong>*</strong> à la place de <strong>yield</strong> et on finit avec un code illisible...).</p>


<p>Python est un des langages les plus lisible mais aussi un des plus paramétrable (j'entend par là entièrement redéfinissable au niveau des mots-clé, des fonctions, etc...). Essayez de ne pas suivre des méthodes reconnues pour être la <a href="http://www.thc.org/root/phun/unmaintain.html">clé de votre engagement à vie dans votre boîte</a> ;-).</p>