Talks Python : l’essentiel en 20 minutes chrono

Les vidéos sur des sujets intéressants autour du développement logiciel sont nombreuses. Comme tout le monde, j’ai une liste “à regarder plus tard” beaucoup trop longue et, comme tout le monde, je n’ai pas le temps de tout regarder. Pour être efficace, voici des fiches sur des talks que je trouve particulièrement intéressants. Normalement, ça prend 20 minutes de lire l’article contre 2 heures pour regarder toutes les vidéos. Bonne lecture !

Ces fiches sont de simples résumés des meilleures pratiques en développement logiciel. Je ne partage pas forcément la même analyse que le speaker. Alors si quelque chose vous paraît suspect, je serai probablement critique à son sujet également. Donc n’hésitez pas à le mentionner en commentaire.

Talk n°1 : « The Mental Game of Python » – Raymond Hettinger, 1h09

TL ; DR : too long; didn’t read!

Ce talk présente des stratégies que les développeurs peuvent suivre pour écrire du meilleur code :

• Utiliser le moins de concepts possible dans une même ligne car un cerveau ne peut manipuler qu’environ 5 concepts en même temps ;
• Écrire des fonctions pour réduire plusieurs concepts en un seul ;
• Faire du développement incrémental ;
• Factoriser tard en laissant d’abord le code se répéter et les patterns apparaître naturellement avant d’écrire des fonctions ;
• Pareil pour la hiérarchie de classes : d’abord, écrire les classes filles, puis laisser les liens apparaître.

Intéressé les conférences software du prestigieux Devoxx ?

👉Découvrez notre article « Devoxx 2024 : retour sur les conférences à voir et à revoir ! »

Plus en détail

Quelques stratégies présentées dans le talk :

Stratégie du chunking

Le cerveau humain est limité, le nombre d’objets pouvant tenir dans la mémoire à court terme d’un humain moyen est de 7, plus ou moins 2. Par exemple :

fruits = [“apple”, “banana”, “orange”]
fruits[int(random() * len(fruits))]

L’expression au-dessus choisit un fruit au hasard, elle utilise 5 registres de notre cerveau car il faut comprendre :

1. La fonction random
2. La fonction len
3. Le résultat de la multiplication de random() * len(fruits)
4. La fonction int
5. L’accès par index à une liste

Alors que l’expression en dessous fait la même chose :

from random import choice
choice(fruits)

Mais elle n’utilise qu’un registre de cerveau car le développeur n’a qu’à réfléchir à ce que fait la fonction choice.

Cacher la complexité est fondamental dans le métier de développeur. On peut dire que c’est tout notre métier : les ordinateurs nous donnent des mots pour qu’on puisse les utiliser, nôtre boulot en tant que développeur est de créer des nouveaux mots pour qu’ils soient plus simples à utiliser. Le speaker raconte que c’est comme ça qu’il explique son métier à ses enfants.

Stratégie de laisser le design émerger du code

C’est très dur de prédire comment un code va évoluer, quel sera le code commun entre plusieurs méthodes, comment des classes seront liées entre elles dans le futur… Décider de ces points dès le début du développement mène parfois à faire de mauvais choix et à s’engager trop tôt dans un design inadapté.

Le mieux est de laisser le code nous l’apprendre de lui-même : plus le temps passe, plus on accumule des informations et plus le design idéal devient évident.

Quand un pattern apparaît, c’est le moment de factoriser. On écrit d’abord des classes filles et quand une hiérarchie apparaît, c’est alors le moment de faire une classe parente.

Par exemple : si on veut écrire une classe pour valider un string, on écrit d’abord ce code :

class String: 
 
    def __init__(self, minsize=0, maxsize=None, predicate=None): 
        self.minsize = minsize 
        self.maxsize = maxsize 
        self.predicate = predicate 
 
    def validate(self, value): 
        if not isinstance(value, str): 
            raise TypeError('Expected a str') 
        if len(value)  self.maxsize: 
            raise ValueError(f'String is too long, must be no bigger than {self.maxsize} long') 
        if self.predicate is not None and not self.predicate(value): 
            raise ValueError(f'Expected {value} to be true for {self.predicate !r}') 

Puis, si on doit écrire un validateur sur une classe fille, on écrit celui-là :

class Number:

def __init__(self, minvalue=None, maxvalue=None):
self.minvalue = minvalue
self.maxvalue = maxvalue

def validate(self, value):
if not isinstance(value, (int, float)):
raise TypeError('Expected an int or float')
if self.minvalue is not None and value  self.maxvalue:
raise ValueError(f'{value} is too big. Must be no more than {self.maxvalue}.')

Puis, on remarque que les deux ont un lien et on peut en extraire une classe parente :

class Validator:

def __set_name__(self, owner, name):
self.private_name = f'_{name}'

def __get__(self, obj, objtype=None):
return getattr(obj, self.private_name)

def __set__(self, obj, value):
self.validate(value)
setattr(obj, self.private_name, value)

class String(Validator):
etc...

class Number(Validator):
etc...

Pourquoi est-il intéressant de regarder le talk en entier ?

Tout simplement pour voir ce qu’est un top speaker, car Raymond Hettinger est l’un des speakers les plus talentueux de la communauté python. Dans cet article, j’ai résumé là où il voulait en venir mais en restant neutre. Je n’ai pas essayé de convaincre alors que lui, il fait ce boulot dans la vidéo. Si vous écoutez tous ses arguments, je pense qu’il réussira à vous convaincre que ses stratégies sont bonnes.

Envie d’en savoir plus concernant les vulnérabilités à prendre en compte lors de tes développements en Python ?

👉Découvrez notre article « 5 failles de sécurité expliquées en Python »

Talk n°2 : « Why python is slow » – Anthony Shaw, 33 minutes

TL ; DR : too long; didn’t read!

Parce que CPython n’a pas de JIT.

Plus en détail

Déjà Python est plus lent que C, Java, etc. Parce qu’il est interprété et aussi parce que c’est dynamiquement typé. Mais si on le compare à Nodejs qui est lui aussi dynamiquement typé et interprète, alors il est bien plus lent ! Alors pourquoi Python est-il plus lent que Nodejs ?

Déjà, il y a le garage collector de Nodejs qui est plus performant que celui de Python. Mais surtout il y a le JIT !

Le JIT

Les JIT sont très efficaces sur les programmes où il y a des “tight loop”, des boucles avec peu d’instruction et beaucoup d’itérations, car un JIT, après les premières itérations, va optimiser la résolution de méthode, de champs, les sauts, etc. Alors que Python résout dynamiquement les types pour chaque opération à chaque itération.

C’est difficile de faire un JIT pour CPython

L’une des principales raisons est qu’une partie du code de CPython est constitué de code C compilé difficile à optimiser. Cependant, tout n’est pas noir car on peut faire tourner du python sur des interpréteurs équipés d’un JIT, comme Numba ou PyPi qui peut être 650 % plus rapide que Cpython.

Mieux encore, Python se révèle plus rapide que Nodejs quand il s’agit d’exécuter non pas des tight loop mais des opérations moins prévisibles comme faire des regex aléatoires sur des strings. Dans ce cas, Python gagne face à JS.

Pourquoi est-il  intéressant de regarder le talk en entier ?

Le speaker parle plus en détail des optimisations que fait un JIT, présente les contraintes d’un JIT, le fonctionnement de CPython etc.

Ce qui n’est plus d’actualité

Le speaker dit que le moteur derrière Node V8 est performant grâce aux équipes de Google qui travaillent dessus alors que CPython est maintenu seulement par des bénévoles. Or ce n’est plus tout à fait vrai, étant donné que Microsoft a engagé Guido Van Rosum et d’autres core développeurs CPython. D’ailleurs, depuis la version 3.13, il y a un JIT inclus dans CPython mais il est désactivé par défaut. Et selon la documentation, les améliorations sont “modestes”.

Besoin d’une boîte à outil complète du développeur Full Stack ?

👉Téléchargez dès maintenant la « Boîte à outil du Développeur Full Stack », faite par des Développeurs Full Stack eux-mêmes !

Conclusion

Regarder un tas de vidéos, c’est cool, mais souvent, on ne retient pas grand-chose de la présentation ou on finit par oublier le contenu, surtout si on ne mobilise pas les connaissances acquises pendant le visionnage. 

C’est pour cette raison que je fais des fiches. Objectif : m’aider à mémoriser les meilleures pratiques en développement logiciel ! Elles s’avèrent en effet très utiles quand on veut se remémorer l’essentiel d’un contenu. En plus, elles constituent une base pour échanger avec vous, lecteurs. Alors si vous trouvez que j’ai mal compris quelque chose à une vidéo ou si vous n’êtes pas d’accord avec mon interprétation, n’hésitez pas à commenter. 

Ici, la première vidéo nous a appris quelques techniques pour écrire du code plus facile à digérer par un cerveau ordinaire. Dans la deuxième, nous avons vu en quoi le JIT est une clé pour améliorer les performances d’un langage. Si vous pensez à une troisième vidéo dont on pourrait parler, précisez laquelle en commentaire.

Vous avez aimé cet article ?

Abonnez-vous à notre newsletter pour ne rien rater de l’actualité Tech et Finance.