Le piège des paramètres par défaut mutables

C’est le “ne pas faire” le plus connu en Python. Mais même en étant au courant on se fait TOUS baiser un jour.

def transfert(source, res=[]):
	# faire un truc qui passe des élement de
	# source à res

Ce code va remplir res d’appels en appels, qui ne sera donc plus une liste vide dès le second appel.

It’s a feature, not a bug, mais c’est pourtant rarement ce qu’on veut.

L’opérateur pour les tuples est la virgule, pas les parenthèses

C’est pratique car ça permet de rendre l’unpacking propre et élégant. Mais c’est aussi un coup à se tirer une balle dans le pied :

>>> t = ("a") # ceci n'est pas un tuple !
>>> type(t)
str
>>> t = "a", # grrrr
>>> type(t) 
tuple
>>> t = () 
>>> type(t) # WAIT WAT ?
tuple

Et comme les string sont itérables, la boucle for marchera toujours, silencieusement, jusqu’à ce que bug s’en suive.

Pas de set literal vide

On peut faire set(), on peut faire {1}, on peut faire () mais on ne peut pas faire {} puisque c’est un dico, ni {,} puisque c’est une syntax error. Ces deux lettres à taper en plus pèsent sur ma conscience.

Le packaging

Packager un programme Python est une grosse galère. Créer un setup.py est facile, mais savoir comment le créer, c’est une autre histoire. En fait le seul tuto valable sur la question est celui de ce blog, et il commence à être vieux. Vous savez pourquoi ? J’ai pas la foi de le mettre à jour car ça veut dire de nouveau passer des heures à me renseigner sur ce qu’il faut faire maintenant.

En fait un exe ou un deb devrait se faire en une ligne de commande.

Les modules inutiles de stdlib

Vous saviez qu’il y a un module pour lire les fichiers WAV dans la stdlib ? Sérieusement, qu’est-ce que ça fout dans la lib standard ?

La convention de langage, pas respectée dans la stdlib

Même après le nettoyage de Python 3, des libs existent qui utilisent le camelcase pour les noms de méthodes comme par exemple unittest. Le code de ces libs lui-même n’est pas PEP8, ce qui craint dès qu’on veut voir comment c’est fait à l’intérieur.

La concaténation automatique fonctionne à côté de l’opérateur virgules

J’adore le fait que :

("1"
"2")

Se concatène automatiquement.

Mais ça devrait lever une syntax error quand c’est déclaré à côté de virgules pour éviter cette merde :

var = (
"1",
"2"
"3"
)

Combien de fois je me suis fait niquer avec ça dans settings.py…

On n’a pas accès au bloc de code dans un with

Il y a des tas de context managers géniaux qu’on pourrait faire si on avait accès au bloc de code exposée dans la close with comme on pourrait le faire avec lisp. Cette limitation m’a frustré plus d’une fois.

Pas de plug de code à chaud

Je rêve de cette feature.

Ecrire du code parallèle, concurrent ou non bloquant est lourd

Syntaxiquement c’est pas top, surtout qu’on doit contourner souvent le GIL. Une grosse amélioration pour l’io async arrive avec la 3.4 mais elle sera surtout bas niveau.

Y a pas de point 10

Ce langage est fantastique.

Ce qui n’est PAS un problème à mes yeux

Le passage à Python 3

A mon sens, brillament exécuté. Je sais que les gens pensent que ça prend un temps fou et que ça a foutu la merde, etc. Mais en vérité, c’est un des rares langages qui ait géré la transition aussi bien : largement documentée, outillée et suivie, bien soutenue par la communauté, avec tout le temps qu’il faut pour la transition mais une direction ferme de la part du BDFL. En plus il est POSSIBLE d’écrire du code qui fonctionne dans les deux versions alors qu’elles sont supposément incompatibles. C’est assez fou quand on y pense.

Il y a d’autres langages qui n’ont jamais réussi ce genre de changements, comme PERL (qui en est mort) ou PHP (qui a avorté).

Les espaces significatifs

Best. Feature. Ever.

Les lambdas sur une ligne

Ne pas toujours pouvoir faire des fonctions anonymes pour les callback, c’est un peu moins élégants, mais sinon, ça ne me manque pas.

L’encoding

Les gens râlent sur la gestion de l’encoding Python parce qu’ils ne comprennent pas ce qu’ils font. Mais personnellement je trouve excellent que le langage te force à gérer CORRECTEMENT tes encodings ou te lève une erreur. J’ai vu tellement de bases de données corrompues, de scripts qui affichent des hiéroglyphes, des “?” plein les pages Web, que je me dis que trop de personnes ignorent juste complètement la question. Et le jour où ça merde, ils passent un mois à réparer.

En 2.7, cette gestion était assez verbeuse par contre, et je suis bien content que ça change en 3.4.