Quelques autres astuces intéressantes dans l'écosystème Python que j'ai oublié de mentionner dans mon journal.
Règles du code source
Bien que de nombreux développeurs sont d'accords pour respecter la PEP-8, on a tous nos préférences pour telle ou telle nuance. Par exemple, personnellement j'apprécie lire des valeurs alignées comme ceci :
Mais ce n'est pas l'avis de tous et chacun a de bons arguments. Par conséquent, du temps précieux est consacré à convaincre/négocier sur tel ou tel aspect. Et puis, avec la rotation naturelle de l'équipe (turn-over), les décisions du passé ne conviennent pas toujours à la nouvelle équipe ! La preuve que l'on y passe du temps, mon bout de code ci-dessus va être repris dans un commentaire plus bas.
Pour mettre tout le monde d'accord, économiser son temps et éviter les polémiques/frustrations, utilisons black. C'est un script python tout-en-un de 4000 lignes qui décide/réécrit tout seul vos fichiers Python. L'absence de fichier de configuration évite tout marchandage. Son objectif est de réduire le diff entre deux commits (minimiser le nombre de lignes modifiés).
Mon code ci-dessus devrait être converti en : (pas testé)
Historiquement, nous avons unittest. D'autres alternatives intéressantes : nose et pytest. Ce dernier permet d'écrire très simplement ses tests unitaires sans avoir à implémenter une classe :
Comme Spack nous le signalait en 2014 et récemment amélioré par Python 3.7, nous pouvons aider l'analyse statique du code source Python en spécifiant les types attendus :
# Autres astuces non mentionnées dans mon journal
Posté par Oliver (site web personnel) . En réponse au journal Quelques bonnes pratiques Python pour 2019. Évalué à 5.
Quelques autres astuces intéressantes dans l'écosystème Python que j'ai oublié de mentionner dans mon journal.
Règles du code source
Bien que de nombreux développeurs sont d'accords pour respecter la PEP-8, on a tous nos préférences pour telle ou telle nuance. Par exemple, personnellement j'apprécie lire des valeurs alignées comme ceci :
Mais ce n'est pas l'avis de tous et chacun a de bons arguments. Par conséquent, du temps précieux est consacré à convaincre/négocier sur tel ou tel aspect. Et puis, avec la rotation naturelle de l'équipe (turn-over), les décisions du passé ne conviennent pas toujours à la nouvelle équipe ! La preuve que l'on y passe du temps, mon bout de code ci-dessus va être repris dans un commentaire plus bas.
Pour mettre tout le monde d'accord, économiser son temps et éviter les polémiques/frustrations, utilisons
black. C'est un script python tout-en-un de 4000 lignes qui décide/réécrit tout seul vos fichiers Python. L'absence de fichier de configuration évite tout marchandage. Son objectif est de réduire lediffentre deux commits (minimiser le nombre de lignes modifiés).Mon code ci-dessus devrait être converti en : (pas testé)
Tests unitaires
Historiquement, nous avons
unittest. D'autres alternatives intéressantes :noseetpytest. Ce dernier permet d'écrire très simplement ses tests unitaires sans avoir à implémenter une classe :Analyse statique de code
Quelques outils intéressants :
Annotation de type
Comme Spack nous le signalait en 2014 et récemment amélioré par Python 3.7, nous pouvons aider l'analyse statique du code source Python en spécifiant les types attendus :
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)