Skip to content

Avec with : plus d’indentations, moins d’instructions

En python, le mot-clef with permet d’ouvrir un bloc dans lequel un contexte spécifique est actif.

L’exemple de « context manager » le plus courant est celui d’une ouverture de fichier qui se ferme automagiquement :

with open('sortie.txt', 'w') as f:
    f.write('Coucou')
f.closed # vaut True

On retrouve cette possibilité dans de nombreux cas comme l’ouverture d’un serveur SMTP :

from smtplib import SMTP
with SMTP("domain.org") as smtp:
    # faire des trucs
#la connection smtp est fermée

L’utilisation d’un « context manager » est adapté à chaque fois qu’il est nécessaire de réaliser des tâches à l’ouverture ou la fermeture (libérer un verrou, fermer une connection, supprimer un fichier, changer une variable globale, etc.). Cela permet de se concentrer ce qu’on veut vraiment faire dans le contexte du with. Les tâches d’ouverture et fermetures sont respectivement déplacées dans les méthodes magiques __enter__() et __exit__(). Si l’on prend en compte l’ensemble du code source, il n’y a donc pas moins d’instructions. Et le titre de l’article peut être considérée comme de la publicité mensongère.

class Pipeau:

    def __enter__(self):
        print("<bonimenteur>")

    def __exit__(self, type, value, traceback):
        print("</bonimenteur>")

with Pipeau():
    print("Prochain article de blog à -50 % !")

# affiche :
# <bonimenteur>
# Prochain article de blog à -50 % !
# </bonimenteur>

Pour plus de détails sur l’utilisation de with, consultez la documentation Python et l’article de sametmax.

Publicités

Ignorer des fichiers, de ack à ag

Ag (the silver searcher), comme ack permettent de chercher des motifs de texte dans du code source. Une sorte de grep spécialisé pour du code source.

Les deux outils sont très probablement disponibles dans votre distribution préférée.
Sous Debian et dérivées :

apt install ack-grep # pour ack
apt install silversearcher-ag # pour ag

ag est plus rapide qu’ack pour trouver des motifs. Un comparatif de performance écrit par le développeur d’ag, qui est donc juge et partie, le montre. Quelques tests rapides m’ont aussi montré un gain de temps.

ack utilise un fichier .ackrc pour ignorer des chemins ou fichiers. ag aussi, mais le format est un peu différent (équivalent à .hgignore et .gitignore qu’il utilise aussi) car il ne fait que de l’exclusion. La modification est triviale pour un castor junior :

$ cat .ackrc
--ignore-dir=riri
--ignore-dir=fifi/
--ignore-dir=loulou

devient
$ cat .ignore
riri
fifi/
loulou

À partir de la version 0.33.0, ag utilise le fichier .ignore et .agignore devient déprécié. Dans la dernière version testée, le fichier .agignore est toujours lu s’il est la racine de ${HOME}, mais non pris en compte s’il est dans le répertoire dans lequel la recherche est faite.

Testé avec les versions suivantes :

ack version 2.12 et 2.18
ag version 0.19.2 et 2.1.0

Coder une variante de FizzBuzz basée sur le jeu 6 qui prend

FizzBuzz est un jeu où l’on compte : lorsqu’un entier est un multiple de 3, on dit « Fizz », multiple de 5 « Buzz », multiple de 3 et 5 « FizzBuzz », dans les autres cas, on dit simplement l’entier. Il est aussi utilisé comme test pour évaluer si quelqu’un maîtrise les bases de la programmation. Une variante, un peu plus compliquée, mais du même type pourrait être réalisée avec le jeu 6 qui prend.

C’est un jeu de cartes dont le but est d’avoir le moins de têtes de bœufs. Les cartes sont numérotées de 1 à 104 (inclus).

Les règles d’estimation de la valeur (en tête de bœufs) des cartes sont relativement similaires aux règles du FizzBuzz :

  • si le nombre est un multiple de 5, la carte vaut 2 têtes de bœufs
  • si le nombre est un multiple de 10, la carte vaut 3 têtes de bœufs
  • si le chiffre des dizaines et des unités sont identiques, la carte vaut 5 têtes de bœufs
  • la carte 55 vaut 7 têtes de bœufs
  • les autres cartes valent 1 tête de bœufs chacune

TL; DR Si on a vraiment du temps à perdre, on finit avec un code de ce genre :

CARTES = 104

def tetes(numero):
    _score = 1
    for diviseur, points in ((10, 1), (5, 1), (11, 4)):
        if _est_multiple(numero, diviseur):
            _score += points
    if numero == 55:
        _score += 1
    return _score

def _est_multiple(numero, diviseur):
    return not numero % diviseur

if __name__ == "__main__": 
    for numero in range(1, CARTES + 1):
        print(numero, "★" * tetes(numero))

Le début de la sortie du terminal :

1 ★
2 ★
3 ★
4 ★
5 ★★
6 ★
7 ★
8 ★
9 ★
10 ★★★
11 ★★★★★
12 ★

Première version

Le code le plus rapide à écrire pour passer les tests devrait ressembler à :

def tetes(numero):
    if numero == 55:
        return 7
    if not numero % 10:
        return 3
    elif not numero % 5:
        return 2
    elif numero >= 10 and str(numero)[0] == str(numero)[1]:
        return 5
    else:
        return 1

if __name__ == "__main__": 
    for numero in range(1, 12):
        print(numero, "*" * tetes(numero))

Améliorations

La règle « le chiffre des dizaines et des unités sont identiques » est équivalent à être un multiple de 11 :

#if numero >= 10 and str(numero)[0] == str(numero)[1]:
if not numero % 11:

Autant factoriser le test de divisibilité :

def tetes(numero):
    _score = 1
    if _est_multiple(numero, 10):
        _score += 1
    if _est_multiple(numero, 5):
        _score += 1
    if _est_multiple(numero, 11):
        _score += 4
    if numero == 55:
        _score += 1
    return _score

def _est_multiple(numero, diviseur):
    return not numero % diviseur

On peut alors remplacer la succession de if par une boucle, et hop, on obtient un code final (qui est au début de l’article).

Tests

Pour valider le programme, quelques assertions de bon aloi sont à ajouter. Ces assertions auront été obtenues au fur et à mesure si on fait du TDD.

import sixquiprend

assert 1 == sixquiprend.tetes(1)
assert 1 == sixquiprend.tetes(2)
assert 2 == sixquiprend.tetes(5)
assert 3 == sixquiprend.tetes(10)
assert 5 == sixquiprend.tetes(11)
assert 5 == sixquiprend.tetes(22)
assert 7 == sixquiprend.tetes(55)

Comportement d’éditeurs de texte lors d’une modification concurrente

Comment se comportent les éditeurs de texte lorsqu’un fichier est ouvert dans l’éditeur et qu’il a été modifié en même temps? C’est la question que vous ne vous êtes probablement jamais posée et à laquelle cet article répond.

TL;DR : plus ou moins bien mais l’écrasement sauvage est évité.

Dans un terminal

Le comportement est le même dans les trois éditeurs testés (nano, vim et emacs-nox). L’éditeur signale le problème lors de l’enregistrement du fichier. Il est possible de choisir alors entre l’état du fichier sur le disque ou celui qui vient d’être modifié.
Par contre, on ne s’en rend compte uniquement lorsque l’on désire enregistrer. Il est toujours possible d’annuler, d’enregistrer le fichier modifié sous un autre nom puis faire la comparaison entre les deux.

Nano

C-o

Vim

:w

Emacs-nox

C-x C-s

Emacs propose un choix supplémentaire : r annule les modifications en cours (pour « reverted »). C-h affiche une explication des différents choix et leurs implications.

En mode fenêtré

Le comportement est similaire dans les éditeurs testés (Gvim, Emacs, Gedit et Kate).
Ils détectent la modification automatiquement et propose de charger le fichier mis à jour. En cas de refus, une nouvelle alerte survient lors de l’enregistrement.

Gvim

Détection de la modification :

Alerte à l’enregistrement :

Emacs

Détection de la modification :

Alerte à l’enregistrement :

Gedit

Gedit est l’éditeur de base fourni avec GNOME.

Détection de la modification :

Alerte à l’enregistrement :

Kate

Kate est l’éditeur fourni avec KDE.

Kate propose une fonctionnalité que les autres n’ont pas : lorsque la modification du fichier est détectée, Kate propose de visualiser la différence entre les deux fichiers (bouton « View difference »). L’affichage obtenu est un diff entre la version sur le disque et la version en mémoire. On pourrait imaginer qu’il ouvrirait le résultat dans un nouvel onglet mais il semble qu’il utilise l’éditeur sélectionné par la variable d’environnement $EDITOR.

Détection de la modification :

Alerte à l’enregistrement :

Méthode et versions utilisées pour les tests (et captures d’écran)

Le comportement n’est pas identique entre les éditeurs lorsque la modification du fichier est faite par la commande
echo 'ajout' >> fichier.txt
Par exemple, la modification en parrallèle est bien détectée par Emacs mais pas par Gedit (la détection à l’enregistrement fonctionne correctement).

Pour avoir un comportement homogène, la méthode utilisée à chaque fois a été d’ouvrir le fichier nommé fichier.txt dans deux éditeurs, le modifier et l’enregistrer dans l’un des éditeurs et regarder comment réagit l’autre.

Nano :
2.8.6

Vim :
VIM – Vi IMproved 8.0 (2016 Sep 12, compiled Jul 22 2017 06:10:49)

Gvim :
8.0.707, version de GNOME 3.22.2

Emacs :
25.2.2, avec le thème deeper-blue

Gedit :
3.22.0, version de GNOME 3.22.2

Kate :
16.08.3, avec KDE 5.28.0 et Qt 5.7.1

L’ensemble des captures d’écran ont été faites sous GNOME.

Meld et Mercurial

Meld est un équivalent graphique de `diff` : il permet de faire des différences entre des fichiers de manière plus visuelle. Mercurial peut utiliser `meld` plutôt que l’outil par défaut lorsqu’il faut afficher des différences entre les fichiers du dépôt local et les fichier du dépôt distant.

Mise en œuvre

Il suffit d’activer l’extension Extdiff fournie avec Mercurial. Cela se fait en ajoutant les lignes suivantes au fichier ~/.hgrc (ou au fichier .hg/hgrc si on souhaite limiter la modification à un répertoire versionné) :

[extensions]
hgext.extdiff =

[extdiff]
cmd.meld =

Différences sur un fichier

Supposons cette modification d’un dépôt :

$ hg diff
diff -r 1915567d21b2 jours.py
--- a/jours.py	Sat Jul 08 15:37:19 2017 +0200
+++ b/jours.py	Sat Jul 08 15:37:59 2017 +0200
@@ -1,12 +1,10 @@
 """Module des jours"""
 
-# Trop simple, faire une fabrique abstraite ?
-
 JOURS = ("lundi",
     "mardi",
     "mercredi",
-    "jedi",
+    "jeudi",
     "vendredi",
     "samedi",
-    "dimenche"
+    "dimanche"
     )

En utilisant la commande `hg meld`, une fenêtre de `meld` s’ouvre, montrant l’état dans le dépôt à gauche et l’état du fichier sur le disque à droite :

Cliquer sur les flèches permet de copier le contenu d’un côté à l’autre automatiquement. Il est aussi possible de modifier le contenu directement.

Différences sur plusieurs fichiers

Avec les modifications suivantes par rapport au dernier commit :

$ hg stat
M annees.py
A siecles.py
R heures.py

Lorsque plusieurs fichiers sont modifiés, `hg meld` affiche un premier panneau permettant de voir les fichiers modifiés (en bleu), ajoutés (en vert), absents (grisé et rayé). En double-cliquant sur un des fichiers, un nouvel onglet s’ouvre, affichant la vue détaillée des différences entre des deux fichiers.

Visualisation de conflits

Si `meld` est disponible, Mercurial s’en servira aussi pour la résolution des conflits.
La partie à gauche est l’état du dépôt local, la partie à droite l’état du dépôt distant et la partie centrale l’ancêtre commun au deux fichiers.

Comme dans le cas précédent, il est possible de modifier les fichiers dans `meld` pour résoudre les conflits.

Versions

Cet article a été fait avec meld, version 3.16.4 et mercurial version 4.0. Il a aussi été validé avec meld, version 1.8.4 et mercurial version 2.8.2.

L’image d’en-tête est une superposition des deux logos (Meld et Mercurial), réalisée avec The Gimp.