pip install yapf

Yapf est un reformateur de code, vous lui filez un fichier (ou un dossier à parcourir récursivement), et il reformate le code pour qu’il soit plus lisible, et plus proche du PEP8.

On en parle en ce moment car le code appartient à Google et que le projet est comparé à gofmt le formatteur intégré à la stack Goland dont les Golois nous ventent les mérites avec moult regards condescendant vers tous les autres langages depuis qu’ils l’ont.

Yapf est loin des features de gofmt pour le moment, mais c’est cool d’avoir un point de départ, car c’est vrai que ça manquait. Non pas que ça n’existait pas déjà, mais les tentatives précédentes n’avaient soulevé aucun enthousiasme, et donc pas beaucoup de contrib. Il a fallut, comme d’hab, qu’un concours de celui qui a la plus grosse motive tout ça à coup d’éGOs, si vous voyez ce que je veux dire. On a bien eu pip intégré à Python parce que les codeurs JS se foutaient de notre gueule avec npm installé par défaut.

Bref, pour le moment yapf s’occupe surtout des espaces et de l’indentation, mais il le fait bien.

Soit le programme suivant :

from __future__ import (unicode_literals, absolute_import, print_function,
    division)
 
    def yolo(a,b =None) :
        print ( "Ca fait mal aux yeux hein ?")
 
        a= 1
 
        if a==b :
            return(b)
 
        if True and      False:# c'est chiant n'est-il pas ?
          return "bob"
 
 
 
    WOLOLO = {
        [1, 2, 3, 4],
        [5, 6, 7, 8],
        [9, 10, 11, 12]
    }
 
    OYOOYO = {
        [1, 2, 3, 4],
        [5, 6, 7, 8],
        [9, 10, 11, 12]
    }  # yapf: disable

Un petit coup de :

yapf programme.py

Et pouf, il vous sort :

from __future__ import (unicode_literals, absolute_import, print_function,
                        division)
 
 
def yolo(a, b=None):
  print("Ca fait mal aux yeux hein ?")
 
  a = 1
 
  if a == b:
    return (b)
 
  if True and False:  # c'est chiant n'est-il pas ?
    return "bob"
 
 
WOLOLO = {[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]}
 
OYOOYO = {
    [1, 2, 3, 4],
    [5, 6, 7, 8],
    [9, 10, 11, 12]
}  # yapf: disable

Yapf existe en ligne de commande, mais peut être utilisé comme une lib. En prime, avec -i, il peut modifier le fichier sur place au lieu de juste faire l’output dans le terminal.

J’espère vraiment qu’il va gagner en traction histoire de pouvoir mettre ça dans tous mes hook git et oublier une bonne fois pour toute les guéguerres de formatage, on a d’autres chattes à coder.

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Utiliser des bons noms est le geste de documentation le plus important d’un code. Je ne parle pas de bien formater le nom des variables. Pour ça, il y a le PEP8 et ce qu’il recommande tient en 3 lignes :

• Le nom des classes en CamelCase
• Les (pseudo) constantes en UPPER_CASE
• Le reste en snake_case

C’est tout.

Non, je parle de choisir un nom adapté et descriptif.

Le post est long, et vous savez que quand le post est long, je vous mets une musique d’attente.

Explicit is better than implicit

En Python, il n’y a pas de déclaration de type. Le nom d’une variable a donc d’autant plus d’importance pour expliquer ce qu’il y a dedans.

Prenez cet exemple :

best = []
for k, v in data.items():
    if v > top:
        best.append(k)

Quand on lit ce bout de code, on se demande :

• Best ? Mais best en quoi ?
• Que contient data ?
• Quel est la nature de top ?

Maintenant, avec des noms explicites :

best_players = []
for player, score in data.items():
    if score > top_score :
        best_players.append(player)

On comprend tout de suite de quoi il est question. L’algo n’a pas changé, seul le nommage a changé.

Et si on passe à une écriture plus compacte, le gain est encore plus net :

best = [k for k, v in data.items() if k > top]

VS

best_players = [player for player, score in data.items() if score > top_score]

Parfois, on veut la concision, mais faute de nommage, on doit se retourner vers les commentaires :

# Get players with the best scores
best = [k for k, v in data.items() if k > top]

Néanmoins, si on doit faire le choix entre commenter et bien nommer, le nommage doit avoir priorité. Le commentaire est important, mais c’est le dernier recours d’un code qui n’est pas explicite. Avoir un code clair doit être l’objectif premier. Ensuite, seulement, on le commente (abondamment toutefois, faut pas être radin).

Si vous avez suivi, je nomme mes variables en fonction de leur nature, pas leur type. On peut utiliser les règles de l’orthographe pour encore plus de précision, par exemple le pluriel.

fruits = ["kiwi", "banane", 'poire']
for fruit in fruits:
    print(fruit)

J’utilise le pluriel pour une liste de données, qui va donc potentiellement contenir plusieurs fruits. Mais j’utilise un singulier dans la boucle pour le fruit en court.

L’utilisation d’adjectifs est aussi bienvenue :

fruits peut devenir, après un traitement filtered_fruits, indiquant que la liste a subi un filtrage. Les mots en “ed” en anglais aident beaucoup à la qualification.

On évite au maximum les variables courtes. Certains cas sont néanmoins tolérés. Le premier est l’utilisation de i, x, yet z pour des indices.

for i, fruit in enumerate(fruits):
    # faire un truc

Les indices sont quelque chose de tellement courant en informatique qu’on ne va pas se gaver à l’appeler “indice” à chaque fois.

Le second est dans le cadre scientifique. On a souvent des variables pour un algo, des coordonnées, des valeurs géométriques ou mathématiques, qui n’ont pas de dénomination. Dans ce cas, inutile d’essayer d’inventer une nomenclature tordue. Exemple typique, l’algo pour pondre un MD5. Mais il faut compenser par des commentaires, sinon on s’y perd.

Il ne faut pas avoir peur des noms longs. Si, j’ai un jeu de données, que je filtre plusieurs fois, il est de bon ton de distinguer les différents jeux avec des noms détaillés :

sample = range(10)
squares = [x * x for x in sample]
even_squares = [x for x in squares if x % 2 == 0]
even_squares_tail = even_squares[-3:]

Faire des noms de plus de 10 caractères n’est pas sale. On est pas sur un tableau des scores d’une borne d’arcade des années 80.

J’utilise bien entendu des noms en anglais, ce qui est toujours préférable, mais si vous devez en mettre en fr, évitez à tout prix les accents malgré la possibilité de les utiliser en Python 3.

Conventions

Il existe quelques noms qui sont toujours utilisés de la même façon en Python.

self et cls sont les plus connus, en j’en parle déjà dans le dossier sur la POO.

Il y a args et kwargs, qu’on utilise avec l’opérateur splat, dont je parle ici.

Et puis il y en a de plus discrets.

_ est utilisé pour une variable qu’on ignore. Certaines opérations, comme l’unpacking, supposent la création de plusieurs variables. Si on n’est pas intéressé par l’une d’elles, on peut le signaler. Par exemple, l’ORM django permet d’obtenir un objet, et si il n’existe pas, de le créer. Cette fonction retourne un tuble (objet, bool), l’élément indiquant si l’objet a été créé ou non. Si cette information nous intéresse :

user, created = User.objects.get_or_create(username="sam")

Si cette information ne nous intéresse pas :

user, _ = User.objects.get_or_create(username="sam")

Ainsi le lecteur saura qu’il peut ignorer cette variable quand il parcourt le code.

Il y a aussi les alias. On ne peut pas utiliser certains noms comme list ou id qui sont des fonctions existantes en Python.

On s’arrange généralement en trouvant un synonyme, mais si ce n’est pas pratique, on change une lettre. list devient lst (rappelez vous que list est un nom déjà assez pourri, nommez plutôt le contenu), class devient klass, dict devient dct, etc.

Si on ne peut pas le faire, la convention est de rajouter un underscore à la fin du nom : id devient id_, max devient max_… Mais faites l’effort, avant, de chercher un synonyme. Je vois trop souvent des from_/to alors que certains contextes permettent parfaitement de les nommer start/end ou source/destination.

A ne pas confondre avec l’underscore AVANT le nom, qui est une convention pour dire qu’une variable ne fait pas partie de l’API publique.

Ce sont des béquilles, le choix d’un nom judicieux et clair est toujours préférable, mais ce sont des béquilles utiles.

Savoir quand nommer

Au-delà de donner un bon nom, il y a le fait de choisir quand il faut nommer, et quand il faut éviter de le faire.

Si seul le résultat final d’un traitement m’intéresse, alors, il vaut mieux utiliser une seule variable et mettre le nouveau résultat dedans à chaque fois :

fstab = [line.strip() for line in open('/etc/fstab') if line]
fstab = [line.lower() for line in fstab if not line.startswith('#')]
fstab = [line.split()[:3] for line in fstab]

il faut aussi savoir quand ne pas du tout créer une variable :

row = line.strip().split()
for col in row:
    # do something

ici, la variable intermédiaire est inutile :

for col in line.strip().split():
    # do something

L’inverse est aussi vrai :

for col in [int(x) for x in line.strip().split()]:
    # do something

La ligne devient beaucoup trop complexe, et ajouter une variable intermédiaire avec un bon nom va améliorer la lisibilité du programme :

numeric_col = [int(x) for x in line.strip().split()]
for col in numeric_col:
    # do something

On pourrait croire que je précise le type ici en utilisant “numeric”, mais je n’ai pas utilisé integer ou float. J’ai précisé la nature : des colonnes numériques. Il se trouve que pour des données aussi brutes, la nature se rapproche du type.

Si vous êtes du genre à utiliser des lambdas, cela s’applique aussi à vous.

Pour quelque chose de simple, une lambda inline est très lisible :

sorted(scores.items(), key=lambda score: score[1])

Mais pour quelque chose de complexe, une fonction complète est bien plus adaptée :

def calculate_rank(score):
    return sum(goals for sort, goal in score[1] if sort == 'A')
 
sorted(scores.items(), key=calculate_rank)

Plutôt qu’un horrible :

sorted(scores.items(), key=lambda x: sum(g for s, g in x[1] if s == 'A'))

Pourquoi je parle de lambda alors qu’on est sur du nommage ? Parce qu’une lambda est anonyme, alors qu’une fonction normale a un nom. Et ce nom exprime l’action de la fonction. Il documente.

Habitudes stylistiques

Ces règles là ne sont pas officielles, mais j’ai pu les constater dans nombre de bons codes.

La nom d’une fonction/méthode est aussi important, sinon plus, que le nom d’une variable. Il n’est pas rare que j’écrive des fonctions avec des noms bien dodus comme :

def get_last_downloaded_shemale_vids()

Si on oublie la docstring, on a déjà une bonne idée de ce que cette fonction fait. Cela n’empêche pas de docstringuer quand même pour annoncer des subtilités sur les types, les potentiels side effects, des choses à savoir sur le temps d’exécution, le format, les perfs, etc.

Mais il arrive souvent qu’une fonction ne fasse pas quelque chose d’aussi concret. Prenez par exemple une fonction dont le but est de sluggifier les strings d’une list.

Si la fonction transforme la liste, on va utiliser un verbe dans le nom :

slugify_items(data)

Si par contre la fonction retourne une liste avec les éléments modifiés, on va utiliser le participe passé :

data = slugified_items(data)

C’est subtil, mais la sémantique est différente. Dans le premier cas, on s’attend à un effet de bord. Dans le second cas, on s’attend à une nouvelle liste, ou comme souvent en Python, à un générateur.

Quand on a affaire à une méthode en Python, on utilise rarement le préfixe get_. Personnellement je l’utilise parfois pour des actions complexes, ou des méthodes de classe.

Mais généralement, on préférera utiliser directement le nom de ce qu’on veut récupérer. Exemple :

comments = blog_post.get_comments(spam=False) # NON
comments = blog_post.comments(spam=False) # Oui

Si on n’a pas besoin de passer de paramètre, alors une property est plus appropriée :

comments = blog_post.comments # Ouiiiiiiiiiiiiiii

J’en profite pour faire remarquer qu’il est très classe de prononcer plusieurs fois très vite “sans paramètre, une propriété est plus appropriée”.

Enfin, il arrive qu’on ait besoin de spécifier des rôles techniques et des interactions entre plusieurs bouts de code : hiérarchie, composition, dépendances, etc. Ce sont les choses les plus compliquées à comprendre quand on lit du code : voir le tableau au complet, ce qui lie les différents blocs.

Il ne faut pas hésiter à nommer ses éléments pour cela. Apprendre le nom des design patterns aide beaucoup, mais même si on n’est pas top moumoute niveau vocabulaire, on peut faire des choses aussi simple que :

class BaseAuthenticator(object):
    #...
 
class PwdAuthenticator(BaseAuthenticator):
    #...
 
class KeyAuthenticator(BaseAuthenticator):
    #...

Si vous lisez BaseAuthentificator, vous n’avez pas besoin de voir qu’elle est parente d’autres classes plus bas pour savoir que ce n’est probablement pas une classe instanciable, mais sans doute une classe interface ou une classe abstraite. De quoi se faciliter une lecture en diagonale.

FAIL

Voici quelques exemples de noms qui ratent complètement l’objectif de documentation :

def do_query_database():
    # ...
 
def query_database():
    # ...
    do_query_database()
    # ...

J’en croise dans le code source de Django, et ça me fait hurler. Sérieux ça veut dire quoi ? Qu’est-ce qui a été extrait ? Dans quel but ? On a plus de question APRÈS avoir lu le nom qu’avant, c’est encore pire qu’un mauvais nom, c’est un nom méchant.

Dans ce cas, il faut essayer d’expliquer au maximum ce que l’appendice – qui va me faire choper une péritonite – que vous avez mis de côté fait :

def excute_and_send_query():
    # ...
 
def query_database():
    # ...
    excute_and_send_query()
    # ...

Un truc également exaspérant, c’est l’usage d’un vocabulaire ambigu :

def make_best_player_list():
    # ...

On sait ce que ça fait, ça fabrique une liste des meilleurs joueurs. Le contexte nous permet d’évaluer le résultat le plus probable. Maintenant un cas beaucoup moins clair :

def make_query():
    # ...

Ca envoie la requête, ça construit la requête ou les deux ? Make est un mot qui peut vouloir dire fabriquer ou exécuter. Ici il vaut mieux utiliser un vocabulaire plus explicite comme :

def build_sql_query():
    # ...

ou

def send_db_query():
    # ...

Là on sait qui fait quoi. Quitte à faire :

def db_query():
    build_sql_query()
    send_db_query()

Et oui, diviser le travail en plusieurs sous unités bien nommées, puis les regrouper dans un bloc plus général est aussi une forme de documentation. Créer des fonctions n’est pas qu’une question de maintenance ou de perf.

Savoir bien nommer les choses vient avec de l’entraînement. Au début, il faut prendre le temps de le faire. Il faut s’arrêter, et se mettre à la place d’un autre dev qui n’a pas encore eu son café.

Allez, détendez-vous, ce blog est plein de code qui ne suit pas les conseils de cet article. Faites juste au mieux ok ?

Ce texte liste les règles stylistiques recommandées, invitant toute la communauté Python à écrire un code de la même façon.

Je vais également y ajouter des éléments de style qui ne sont pas dedans, mais que j’ai pu constater comme étant les choix les plus courants dans les sources que j’ai pu lire.

Espaces

Les opérateurs doivent être entourés d’espaces.

Il faut faire ceci :

variable = 'valeur'
 
ceci == cela
 
1 + 2

Et non:

variable='valeur'
 
ceci==cela
 
1+2

Il y a deux exceptions notables.

La première étant qu’on groupe les opérateurs mathématiques ayant la priorité la plus haute pour distinguer les groupes :

a = x*2 - 1
b = x*x + y*y
c = (a+b) * (a-b)

La seconde est le signe = dans la déclaration d’arguments et le passage de paramètres :

def fonction(arg='valeur'): #  ça c'est ok
    pass
 
resultat = fonction(arg='valeur') #  ça aussi

On ne met pas d’espace à l’intérieur des parenthèses, crochets ou accolades.

Oui :

2 * (3 + 4)
 
def fonction(arg='valeur'):
 
{str(x): x for x in range(10)}
 
val = dico['key']

Non :

2 * ( 3 + 4 )
 
def fonction( arg='valeur' ):
 
{ str(x): x for x in range(10) }
 
val = dico[ 'key' ]

On ne met pas d’espace avant les deux points et les virgules, mais après oui.

Oui :

def fonction(arg1='valeur', arg2=None):
 
dico = {'a': 1}

Non :

def fonction(arg='valeur' , arg2=None) :
 
dico = {'a' : 1}

Lignes

Une ligne doit se limiter à 79 charactères. Cette limite, héritée des écrans touts petits, est toujours en vigeur car il est plus facile de scanner un code sur une courte colonne qu’en faisant des aller-retours constant.

Si une ligne est trop longue, il existe plusieurs manières de la racourcir :

foo = la_chose_au_nom_si_long_quelle_ne_tient_pas_sur(
          une, 
          carte, 
          de, 
          munchkin)

Ici l’indentation entre le nom de la fonction et des paramètres est légèrement différente pour mettre en avant la distinction.

Une variante :

foo = la_chose_au_nom_si_long_quelle(ne, tient, pas, sur, carte 
                                     une, de, munchkin)

Si c’est un appel chainé, on peut utiliser \ pour mettre à la ligne :

queryset = ModelDjangoALaNoix.objects\
                             .filter(banzai=True)\
                             .exclude(chawarma=False)

Si c’est une structure de données, on peut se la jouer langage fonctionel de la vibes du flex :

chiffres = [
    1, 2, 3,
    4, 5, 6,
]
 
contacts = {
    'Cleo': (),
    'Ramses': (
        ('maman', '0248163264'),
        ('papa', '01234567890'),
        ('mamie', '55555555'),
        ('momie', '066642424269')
    )
}

Séparer les fonctions et les classes à la racine d’un module par 2 lignes vides. Les méthodes par 1 ligne vide. Parfois je triche et je fais 3 et 2 au lieu de 2 et 1.

Les imports de plusieurs modules doivent être sur plusieurs lignes :

import sys
import os

Et non :

import sys, os

Bien sûr, ce n’est pas valable pour from x import z.

Souvenez-vous qu’on peut utiliser les parenthèses pour diviser de longues lignes. Par exemple :

from minibelt import (dmerge, get, iget, normalize, 
                      chunks, window, skip_duplicates, flatten)

Idem pour les chaînes très longues :

s = ("Les chaînes Python sont automatiquement"
     "concaténées par la VM si elles sont "
     "uniquement séparées par des espaces "
     "ou sauts de lignes.")

Pour en revenir aux lignes d’import, on doit les ordonner ainsi :

• Import de module > import du contenu du module
• Import de la lib standard > import de libs tierces parties > import de votre projet

Exemple :

import os  # import module de la lib standard
import sys # on groupe car même type 
 
from itertools import islice  # import du contenu du module
from collections import namedtuple # import groupe car même type
 
import requests # import lib tierce partie
import arrow # on groupe car même type
 
from django.conf import settings # tierce partie, contenu du module
from django.shortcuts import redirect # on groupe car même type
 
from mon_projet.mon_module import ma_bite # mon projet

Format du fichier

Indentation : 4 espaces. Pas de tab. C’est tout. Ce n’est pas du PEP8, c’est juste que les codes qui utilisent les tabs sont en (très très très très très très très très) grande minorité dans la communauté Python. Donc faites pas chier. Sinon on vous attend à la sortie de l’école. Tous.

Encoding : UTF8 ou ASCII (ce qui est de l’UTF8 de toute façon).

Docstrings

(c.f. PEP257)

On utilise toujours des triples quotes :

def fonction_avec_docstring_courte():
    """Résumé en une ligne."""
    pass

Si la docstring est longue (elle peut être très très très longue si vous le souhaitez) :

def fonction():
    """Résumé en une ligne suivi d'une line vide.
 
    Description longue de la fonction qui 
    se termine par une ligne vide puis une
    triple quotes sur sa propre ligne.
 
    """

Noms de variables

Lettres seules, en minuscule : pour les boucles et les indices.

Exemple :

for x in range(10):
    print(x)
 
i = get_index() + 12
print(ma_liste[i])

Lettres minuscules + underscores : pour les modules, variables, fonctions et méthodes.

une_variable = 10
 
def une_fonction():
    return locals() or {}
 
class UneClasse:
    def une_methode_comme_une_autre(self):
        return globals()

Lettres majuscules + underscores : pour les (pseudo) constantes.

MAX_SIZE = 100000  # à mettre après les imports

Camel case : nom de classe.

class CeciEstUneClasse:
    def methodiquement(self):
        pass

Si le nom contient un acronyme, on fait une entorse à la règle :

class HTMLParserCQFDDDTCCMB:
    def methodiquement(self):
        pass

On n’utilise PAS le mixedCase.

D’abord, les techniques habituelles de substitutions de lettres par leurs codes ASCII sont toujours valables. Le fameux easter egg import this en fait d’ailleurs usage; si vous ouvrez le fichier dont le chemin est contenu dans this.__file__, vous trouverez :

s = """Gur Mra bs Clguba, ol Gvz Crgref
 
Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""
 
d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)
 
print "".join([d.get(c, c) for c in s])

Ensuite, il y a le fait qu’il est possible de spécifier (en Python 2.7, mais plus Python 3), l’encoding du module en ROT13, base64 ou même zip. Au lieux de mettre # -*- coding: utf8 -*-, vous pouvez faire :

# -*- coding: rot13 -*-
 
cevag h'Fnz rg Znk, cnepr dhr obver frhy rfg zbvaf qebyr dhr pbqre n cyhfvrhef'

Mais au dela de ces petites astuces, il y a bien entendu la véritable offuscation, celle qui utilise des imbrications d’instructions capilotractées avec de multiples niveaux de nesting dans des onliners qui s’étendent sur des kilomètres en incluant des noms de variables alambiqués le tout organisé dans des structures syntaxiques volontairement obscures en détournant des capacités du langage pour en faire une indigeste bouillie immonde dont la lecture provoquera des saignement durant la phrase de vomi. Comme cette phrase.

Généralement ça passe par un usage massif des features que Guido déteste comme les lambdas ou les ;.

Il y a les classiques onliners à base de map / reduce, par exemples les 1000 premiers nombres … premiers :

print filter(None,map(lambda y:y*reduce(lambda x,y:x*y!=0, map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))

Ensuite il y a ceux qui aiment se la jouer “mes variables ont des noms de code Fortran” :

print (lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
>=4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(
64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24)

Ce qui va afficher cette belle composition de Mandelbrot (si votre terminal fait 80 colonnes de large) :

La génération procédurale : ou comment faire de Zolies choZes avec 1ko de code.

D’ailleurs, pour l’offuscation, on adore les trucs de maths parce que ça donne l’air intelligent et compliqué, et Mandelbrot est un truc très prisé puisqu’avec peu de lignes on peut outputer du Dali Période Guimauve automatiquement :

_                                      =   (
                                        255,
                                      lambda
                               V       ,B,c
                             :c   and Y(V*V+B,B,  c
                               -1)if(abs(V)<6)else
               (              2+c-4*abs(V)**-0.4)/i
                 )  ;v,      x=1500,1000;C=range(v*x
                  );import  struct;P=struct.pack;M,\
            j  ='<QIIHHHH',open('M.bmp','wb').write
for X in j('BM'+P(M,v*x*3+26,26,12,v,x,1,24))or C:
            i  ,Y=_;j(P('BBB',*(lambda T:(T*80+T**9
                  *i-950*T  **99,T*70-880*T**18+701*
                 T  **9     ,T*i**(1-T**45*2)))(sum(
               [              Y(0,(A%3/3.+X%v+(X/v+
                               A/3/3.-x/2)/1j)*2.5
                             /x   -2.7,i)**2 for  \
                               A       in C
                                      [:9]])
                                        /9)
                                       )   )

Notez cette fois que le code, en plus d’être particulièrement imbuvable, a été gentiment indenté pour ressembler à la figure qu’il va lui même pondre dans le fichier M.bmp que voici :

Mais bien entendu il y a des gens qui arrivent à faire des trucs moches sans entrainement. Par exemple des codeurs JS qui vous font ça:

if "longue chaine".find('chaine') != -1:

Au lieu de :

if 'chaine' in 'longue chaine':

Ou alors les programmeurs C qui font :

for x in range(0, len(ma_list)):
    print ma_list[x]

Alors qu’on a :

for x in ma_list:
    print x

Et au besoin:

for i, x in enumerate(ma_list):
    print i, x

Et à peu près la moitié des programmeurs d’autres langages qui font :

if truc == True:
    if not len(ma_list):

Alors que:

if truc:
     if not ma_list:

Marche très bien.

Je vous passe les isintance() que nous font les programmeurs Java, les check au lieu des gestions des exceptions et les gens qui écrivent les variables en camelCase. Des gens très compétents font du code horrible.

Certains trouvent que le créateur du langage a été un nazi pour avoir forcé les gens à utiliser l’indentation et les sauts de ligne ou pour avoir limité les lambdas. Quand je lis le code de certains, j’ai tendance au contraire à trouver la politique actuelle proche de l’anarchisme hippie. Interdisons les tabs. Les “;” plus de 3 fois d’affilé. Les nombres de saut de ligne qui ne sont pas standard face au PEP8. En fait faisons des syntax errors sur le PEP8. Et les syntaxes errors déclencheront des chocs électriques via le clavier.

Et on enverra tous ceux qui sont pas d’accord dans des camps d’entraînement pour qu’ils puissent tous se concentrer un peu plus sur leur code.

Sinon à quoi ça sert d’être un BDFL ?

Par exemple:

class Truc(threading.Condition):
    pass
 
class Machine(tempfile.NamedTemporaryFile):
    pass

Lèveront l’exception :

TypeError: Error when calling the metaclass bases 
    function() argument 1 must be code, not str

Car:

>>> import threading, tempfile
>>> type(threading.Condition)
<type 'function'>
>>> type(tempfile.NamedTemporaryFile)
<type 'function'>

Malgré leurs noms en majuscule.

Le message d’erreur est lui-même complètement obscure. Bref, le genre de truc qui est 100% lié à des erreurs d’autres personnes que vous aller payer par une après-midi de debug si on ne vous donne pas la solution.

Mais bon, la queue de celui qui n’a jamais pourri l’après-midi d’un autre codeur avec son travail merdique jette le premier parpaing.