• Vous avez oublié de faire ‘add’ ou ‘commit’ et fait un ‘push’ directement
• Vous n’avez pas de référence vers votre ‘remote’

Le premier est facile à résoudre, le second est moins intuitif.
Un ‘remote’ est une référence vers un autre depot. Si vous travaillez avec plusieurs dépôts en parallèle, et que vous souhaitez faire ‘pull’ depuis le premier, puis ‘push’ vers le second, alors il faut ajouter cette référence puis une référence vers une branche. Cela donne:

git remote add new_repo git://path/to/new/repo # on ajoute le nouveau remote
git fetch new_repo # on met à jour les références locales
git checkout -b remote_master new_repo/master # créer 1 branch depuis son master
git merge origin/master # on merge les deux master
git push new_repo master # on push vers le remote

sudo gedit /etc/udev/rules.d/51-android.rules

Mettre la ligne:

SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", MODE="0666"

Redemarrer.

Nous allons voir maintenant comment récupérer une ancienne version du code et comment se déplacer dans l’historique.

Pour faire ce tuto, vous devrez :

• Avoir fait le tuto précédent.
• Travailler sa souplesse d’esprit, car ce que l’on va voir n’a rien à voir avec ce que vous aviez probablement appris avec des outils type SVN.

Temps de lecture : 1h

Découvrez les branches

Hein ? Les branches ? Mais on ne devait pas parler de restauration de document avant de faire des branches ?

Rassurez vous, on ne vas pas créer ni changer de branche, on va juste expliquer ce que c’est.

De manière étonnante, on ne peut pas faire du travail sérieux dans Git sans comprendre comment fonctionnent les branches car :

• On travaille dès le début sur une branche.
• Les opérations de déplacement utilisent la notion de branche.
• Les branches ne sont probablement pas du tout ce que vous croyez.

En vérité, les branches ne sont pas des branches d’un arbre virtuel comme par exemple sur SVN. Elles sont de simples marqueurs, au même titre que HEAD mais avec une fonction différente. Ce sont des panneaux qui indiquent « cette partie du travail avance à partir d’ici ».

Par exemple, si vous travaillez sur une version Linux et une version Mac de votre programme, vous pouvez avoir avez deux branches, « linux-version » et « mac-version », ainsi disposées :

Attention cependant, une branche n’est pas une succession de changesets.

Ainsi, la divergence de l’historique qui inclut « Nouveau changeset » et « Finalement le TODO est bien comme cela » n’est pas la branche « linux-version ». C’est juste une succession de changesets. La branche « linux-version », c’est uniquement la partie verte sur le schéma, c’est un panneau qui pointe sur un changeset pour dire « la branche est ici ».

Ainsi, on peut très bien avoir deux branches sur un historique linéaire :

La branche n’a donc rien à voir avec les directions que prend l’historique, c’est uniquement un petit point dans l’historique. Du coup la métaphore de l’arbre en prend un coup avec Git

Autre chose : HEAD et les branches sont des concepts différents. HEAD, c’est le pointeur pour vous dire où VOUS êtes. Les branches, ce sont des pointeurs pour dire « ici se trouve une certaine version de mon code ».

Vous allez me dire que cela ressemble beaucoup au tags, et c’est vrai, mais la grosse différence est que les branches bougent. En particulier, si vous êtes sur une branche et que vous faites un commit, la branche se déplace sur le nouveau changeset avec vous.

Quand vous créez un dépôt Git, une branche est créée automatiquement et placée sur le premier changeset. C’est branche est appelée « master ». La branche « master » n’a rien de spéciale, c’est une branche comme une autre, mais elle existe depuis le début et porte toujours ce nom.

Ainsi, si vous avez gardé le dépôt que vous avons créé lors de notre dernier tuto, on se trouve dans la situation suivante :

Quand on est sur une branche et que l’on fait un commit, la branche est déplacée sur le nouveau changeset. Du coup, la branche « master » vous a suivi jusqu’ici. Cependant, vous devez comprendre que HEAD et la branche actuelle sont indépendants, et donc on peut bouger HEAD sans déplacer la branche.

Annuler un commit avec « git commit –amend »

Parfois vous ferez une sauvegarde dont vous ne voulez pas.

Dans ce cas, faites vos modifications telles que vous voudriez qu’elles soient, puis au lieu de faire « git commit », effectuez « git commit –amend » : le précédent commit est alors supprimé et remplacé par le précédent commit.

Par exemple, on ajoute « Super ! » dans text.txt, et on créé un fichier nommé proto.txt. Il reste aussi des modifications sur TODO.txt que nous n’avions pas enregistrées la dernière fois :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   TODO.txt
#	modified:   test.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	proto.txt
no changes added to commit (use "git add" and/or "git commit -a")

Ajoutons nos deux modifications, mais pas la création, puis commitons :

$ git add TODO.txt
$ git add test.txt
$ git commit -m "Je le sens pas ce commit"
[master b415af6] Je le sens pas ce commit
 2 files changed, 2 insertions(+), 0 deletions(-)
$ git log
commit b415af6c2e48a8f77fc12caea380f8f7e7345b81
Author: ksamuel <mail@e-vidence.net>
Date:   Mon Mar 29 16:55:10 2010 +0000
 
    Je le sens pas ce commit
 
commit 1a0633ce778044aadea23eb39cdc21fc6c949989
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 21:08:04 2010 +0000
 
    On sauvegarde l'index dans l'historique
[…]

On s’apperçoit qu’on a oublié le fichier « proto.txt ». Si on fait un second commit, il sera pris en compte. Mais si quelqu’un récupère le code du précédent commit, il lui manquera ce fichier !

Annulons plutôt le précédent commit après avoir ajouté « proto.txt » :

$ git add proto.txt
$ git commit --amend -m "Je savais bien que j'avais oublié quelque chose"
[master a9c07b1] Je savais bien que j'avais oublié quelque chose
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 proto.txt
$ git log
commit a9c07b154a6d2e3b2435fa51bbc3a920fb1652b2
Author: ksamuel <mail@e-vidence.net>
Date:   Mon Mar 29 16:55:10 2010 +0000
 
    Je savais bien que j'avais oublié quelque chose
 
commit 1a0633ce778044aadea23eb39cdc21fc6c949989
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 21:08:04 2010 +0000
 
    On sauvegarde l'index dans l'historique
[…]

Nous avons donc fait :

Retourner à une version antérieur avec « git reset »

« git reset » permet de déplacer la branche actuelle dans l’historique. Par exemple, si vous êtes au niveau de « master », vous pouvez faire pointer « master » sur un autre changeset. Par défaut, « git reset » va aussi prendre tous les changements du changesets et le mettres dans l’index, comme ça seule votre copie de travail est en décalage avec le changeset et « git status » vous donne un résultat cohérent.

Le HEAD est déplacé en même tant que la branche actuelle. Après un « reset », les deux pointent sur le nouveau changeset.

Par exemple, supposons qu’on veuille replacer la branche master à l’époque de l’ajout du .gitignore :

$git log
[...]
commit 9f2f748ecb853a1cb616b6d387f7169dac32f243
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:12:18 2010 +0000
 
    Ajout d'un fichier et suppression d'un autre
 
commit e3bfc5d3457756d695bbed735ea018559d8b00cd
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:52:12 2010 +0000
 
    Ajout du .gitignore
 
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire

On voit que le hash de ce changeset est e3bfc5d3457756d695bbed735ea018559d8b00cd, donc on fait un reset avec ce hash :

$ git reset e3bfc5d3457756d695bbed735ea018559d8b00cd
Unstaged changes after reset:
M	README.txt
M	TODO.txt
M	tuto.txt

Notre HEAD s’est bien déplacé sur ce changeset car maintenant le log ne nous affiche plus les autres changesets :

$ git log
commit e3bfc5d3457756d695bbed735ea018559d8b00cd
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:52:12 2010 +0000
 
    Ajout du .gitignore
 
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire

Et on peut voir que l’index a été mis à jour mais que votre copie de travail est restée intacte car « git status » nous indique des changements :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    README.txt
#	modified:   TODO.txt
#	deleted:    tuto.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	proto.txt
#	test.txt

A ce stade vous avez peut-être envie de revenir tout en haut de l’historique, mais « git log » ne vous donne plus la référence pour le faire !

C’est normal, « git log » vous indique le log telle que vu par la branche courrante. Il existe heureusement une commande qui vous permet de voir toutes les valeurs qu’on a donné à HEAD depuis le début, c’est « git reflog » :

$git reflog
e3bfc5d HEAD@{0}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{1}: commit (amend): Je savais bien que j'avais oublié quelque chose
b415af6 HEAD@{2}: commit: Je le sens pas ce commit
1a0633c HEAD@{3}: commit: On sauvegarde l'index dans l'historique
edfb9d2 HEAD@{4}: commit: Finalement le TODO est bien comme ça
9f2f748 HEAD@{5}: commit: Ajout d'un fichier et suppression d'un autre
e3bfc5d HEAD@{6}: commit: Ajout du .gitignore
bbfc3cf HEAD@{7}: commit (initial): Ceci est un commentaire

On voit que HEAD s’est pas mal baladé ! Le changeset qui nous intéresse est l’avant dernier (son hash abrégé est le numéro tout à gauche), et on peut y retourner avec « git reset » bien entendu :

$ git reset a9c07b1
$ git log
commit a9c07b154a6d2e3b2435fa51bbc3a920fb1652b2
Author: ksamuel <mail@e-vidence.net>
Date:   Mon Mar 29 16:55:10 2010 +0000
 
    Je savais bien que j'avais oublié quelque chose
 
commit 1a0633ce778044aadea23eb39cdc21fc6c949989
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 21:08:04 2010 +0000
 
    On sauvegarde l'index dans l'historique
[…]

Les options de git reset

« git reset » possède deux options « –soft » et « — hard », qui permettent de changer son comportement.

« –soft » fait la même chose qu’avant, mais ne met pas à jour l’index. Vous gardez votre index d’origine, ainsi vous pouvez faire un commit directement et sauvegarder le contenu de l’index. Refaisons la même opération que précédemment avec « –soft » :

$ git reset --soft e3bfc5d3457756d695bbed735ea018559d8b00cd
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    README.txt
#	modified:   TODO.txt
#	new file:   proto.txt
#	new file:   test.txt
#	deleted:    tuto.txt
#

Le status nous dit que tous les changements sont près à être sauvegardés car l’index n’a pas été modifié.

On retourne à notre commit final :

$ git reset a9c07b1

Voyons maintenant l’option « –hard », qui elle met en plus à jour la copie de travail. Tous vos fichiers sont donc écrasés et remplacés par ceux issu du changeset vers lequel vous vous déplacez :

$ ls
divers  proto.txt  README.txt  test.txt  test.txt~  TODO.txt  TODO.txt~  tuto.txt
$ git reset --hard e3bfc5d3457756d695bbed735ea018559d8b00cd
HEAD is now at e3bfc5d Ajout du .gitignore
$ ls
divers  README.txt  test.txt~  TODO.txt  TODO.txt~  tuto.txt

Vous voyez que les fichiers de la copie de travail ont aussi changé. Du coup pour revenir à notre commit final et avoir les fichiers du commit final, il faut utiliser « –hard » également :

$ git reset --hard a9c07b1
HEAD is now at a9c07b1 Je savais bien que j'avais oublié quelque chose

Vous voyez que le log des références contient maintenant la liste de nos nombreux allers-et-retours :

$ git reflog
a9c07b1 HEAD@{0}: a9c07b1: updating HEAD
e3bfc5d HEAD@{1}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{2}: a9c07b1: updating HEAD
e3bfc5d HEAD@{3}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{4}: a9c07b1: updating HEAD
e3bfc5d HEAD@{5}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{6}: a9c07b1: updating HEAD
e3bfc5d HEAD@{7}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{8}: commit (amend): Je savais bien que j'avais oublié quelque chose
b415af6 HEAD@{9}: commit: Je le sens pas ce commit
1a0633c HEAD@{10}: commit: On sauvegarde l'index dans l'historique
edfb9d2 HEAD@{11}: commit: Finalement le TODO est bien comme ça
9f2f748 HEAD@{12}: commit: Ajout d'un fichier et suppression d'un autre
e3bfc5d HEAD@{13}: commit: Ajout du .gitignore
bbfc3cf HEAD@{14}: commit (initial): Ceci est un commentaire

Le mien est sans doute un peu différent du votre car j’ai fais une ou deux coquilles durant la rédaction du tuto

Pour récapituler :

• « git reset » permet de déplacer la branche courante ainsi que le HEAD. L’index est mis à jour pour refléter le nouveau changeset.
• « –soft » permet d’éviter que l’index soit mis à jour.
• « –hard » permet de mettre à jour aussi la copie de travail.
• « git reflog » permet de voir tout l’historique des références de HEAD (c’est à dire partout où vous êtes allé).

Deux usages de « reset » courant

On utilisera souvent pour deux opérations très courantes.

La première, c’est annuler tous les ajouts dans dans l’index. Par exemple, on s’aperçoit qu’on a fait « git add . » et que plein de choses sont prêtes à être sauvegardées par erreur. Il suffit de faire :

$ git reset HEAD

En effet, on se déplace jusqu’à HEAD (mais on y est déjà puisque HEAD c’est le commit actuel, donc ça ne change rien), et on met tout le contenu du dernier changeset dans l’index. Donc l’index est remis à zéro.

La seconde utilisation est de remettre à plat sa copie de travail. Par exemple on a fait des tas de modifications inutiles sur les fichiers et on veut recommencer à zéro avec les fichiers propres du dernier commit :

$ git reset HEAD --hard

En effet, on se déplace jusqu’à HEAD (mais on y est déjà puisque HEAD c’est le commit actuel, donc ça ne change rien), et on met tout le contenu du dernier changeset dans l’index, puis met à jour la copie de travail pour qu’elle ressemble exactement à son état lors du dernier commit.

« git reset » sur des fichiers

« reset » peut aussi s’appliquer directement à des fichiers, mais dans ce cas on ne peut faire ni « –hard » ni « –soft ». La seule chose que cela produit est la mise à jour de l’index. On l’utilise surtout pour annuler une modification de l’index, par exemple, supposons que je supprime TODO.txt :

$ rm TODO.txt
$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    TODO.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

La suppression de mon fichier est notée comme “détectée ma pas à sauvegarder”. Je dis à Git que je veux qu’il enregistre cette surpression.

$ git rm TODO.txt
rm 'TODO.txt'
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    TODO.txt
#

Maintenant, si je fais un commit, cette suppression est enregistrée. Mais si je change d’avis ? « reset » me permet de récupérer le TODO.txt qui est dans HEAD pour le mettre dans l’index.

$ git reset -- TODO.txt
Unstaged changes after reset:
M	TODO.txt
$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    TODO.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Et voilà, la supression ne sera pas enregistrée si je fais un commit.

Mais vous devez vous demander, qu’est-ce que signifie « — ». Ceci n’a rien à voir avec Git, c’est un marqueur utilisé dans n’importe quelle ligne de commande pour dire qu’il n’y a plus d’option après lui. Il n’est pas utile d’entrer dans les détails, tout ce que vous avez besoin de savoir c’est qu’il faut le mettre juste avant le nom du fichier que l’on veut remettre à zéro dans l’index.

Enfin, pour les besoins de l’exercice, nous alons faire un hard reset pour mettre notre copie de travail au propre :

$ git reset –hard HEAD

Et voilà, retour à la case départ

« git checkout »

La commande « checkout » toute seule ressemble beaucoup à un « reset –hard » : elle permet de se déplacer dans l’historique à un point donné et l’index ainsi que la copie de travail sont mis à jour :

$ ls
divers  proto.txt  test.txt  test.txt~  TODO.txt  TODO.txt~
$ git log
[...]
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire
 
$ git checkout bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Note: moving to 'bbfc3cf5ef3f93c4aab17b39193907a047b5617b' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at bbfc3cf... Ceci est un commentaire
$ git log
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire
 
$ ls
divers  README.txt  test.txt~  TODO.txt  TODO.txt~  tuto.txt

Vous voyez ici la copie de travail telle qu’elle était à notre premier commit. Vous voyez de plus text.txt~ car il est dans le .gitignore et n’a donc pas été touché. Attention cependant :

$ git status
# Not currently on any branch.
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	TODO.txt~
#	test.txt~

Le .gitignore n’avait pas été créé à cette époque, du coup à ce niveau de l’historique, Git voit ces fichiers

Revenons à la case départ grâce au reflog :

$ git reflog
bbfc3cf HEAD@{0}: checkout: moving from master to bbfc3cf5ef3f93c4aab17b39193907a047b5617b
a9c07b1 HEAD@{1}: a9c07b1: updating HEAD
e3bfc5d HEAD@{2}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{3}: a9c07b1: updating HEAD
e3bfc5d HEAD@{4}: e3bfc5d3457756d695bbed735ea018559d8b00cd: updating HEAD
a9c07b1 HEAD@{5}: a9c07b1: updating HEAD
[…]
$ git checkout a9c07b1
Previous HEAD position was bbfc3cf... Ceci est un commentaire
HEAD is now at a9c07b1... Je savais bien que j'avais oublié quelque chose
$ ls
divers  proto.txt  test.txt  test.txt~  TODO.txt  TODO.txt~

Jusqu’ici, pas très utile, on savait déjà faire ça avec « reset ».

Il y a pourtant une différence primordiale : contrairement à « reset », « checkout » ne déplace pas la branche courante, ce qui fait que si vous vous déplacez dans un endroit sans branche, vous travaillez en dehors de toute branche ! Un problème important, que nous verrons dans un autre article.

De plus, « checkout » permet de faire quelque chose que « reset » ne fait pas : récupérer un fichier de l’historique et l’importer dans la copie de travail. Pour cela, il suffit de lui passer en paramètre le nom du fichier.

Supposons qu’on veuille récupérer TODO.txt tel qu’il était 2 commits avant :

$ git log
commit a9c07b154a6d2e3b2435fa51bbc3a920fb1652b2
Author: ksamuel <mail@e-vidence.net>
Date:   Mon Mar 29 16:55:10 2010 +0000
 
    Je savais bien que j'avais oublié quelque chose
 
commit 1a0633ce778044aadea23eb39cdc21fc6c949989
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 21:08:04 2010 +0000
 
    On sauvegarde l'index dans l'historique
 
commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:19:33 2010 +0000
 
    Finalement le TODO est bien comme ça
 
commit 9f2f748ecb853a1cb616b6d387f7169dac32f243
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:12:18 2010 +0000
 
    Ajout d'un fichier et suppression d'un autre
[…]
$ git checkout 9f2f748ecb853a1cb616b6d387f7169dac32f243 TODO.txt

Et voilà TODO.txt revenu à son état d’origine :

- Devenir un expert en Python.
- Créer mon premier site avec Django.
- Penser "ergonomie" dès le départ pour mon prochain dév.

La copie de travail et l’index sont mis à jour, du coup, la modification est prêt à être sauvegardée :

$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   TODO.txt
#

Retour à l’état départ :

$ git reset --hard HEAD

En résumé :

• « git checkout hash » permet de se placer dans un endroit dans l’historique, mais ne déplace pas la branche courante. On préfère souvent utiliser « reset » pour ce genre de chose, sauf si on sait très bien ce qu’on fait.
• « git checkout hash nom_de_fichier » permet de récupérer un fichier issu d’un changeset et de le mettre dans l’index et la copie de travail courante. Très très utile !

Il est aussi possible de récupérer un fichier issu de l’index en effectuant :

$ git checkout -- nom_de_fichier

En pratique, on l’utilise rarement.

Finis !

La prochaine fois nous verrons plus en détails le principe des tags, des branches et finalement de comment fusionner des modifications entre elles avec « merge ».

Mais voilà, après avoir découvert qu’il n’y a presque pas de ressources en français sur l’outil, vous avez lu Pro Git, vous avez posé des questions sur StackOverflow et vous n’arrivez toujours pas comprendre ce que veulent dire les incantations runiques du genre :

git reset --mixed HEAD~1

Tout le monde sur les fora vous disent que c’est pourtant évident, et vous vous sentez très bête. Non ? Bon, c’est juste moi alors.

Don’t panic ! Avec l’espoir de prévenir une nouvelle dépendance à l’aspirine chez les développeurs agiles, on va se faire quelques tutos e-vidents.

Pas de présentation de l’outil

Je pars du principe que vous savez utiliser un système de gestion des sources. Ce n’est pas un cours de gestion de projet, mais une aide de prise en main d’un outil. Et je ne vous ferai pas la pub de Git non plus, si vous êtes là, c’est que vous êtes a priori intéressés (et en plus je trouve Mercurial plus simple, mais bon, c’est moins classe sur le CV).

Pour suivre ce tuto vous avez donc besoin :

• D’avoir utilisé précédemment un outil de gestion de sources quelconque (SourceSafe ne compte pas). J’inclurai des références à SVN, donc bonus pour ses utilisateurs.
• D’être capable d’oublier tout ce que vous avez appris avec cet outil de gestion de sources. Parce qu’il va y avoir pas mal de remise en cause.
• Savoir vous servir de la ligne de commande. Dépendants de Tortoise, allez voir chez Hg si j’y suis. Je sais ça craint, mais si vous cherchez sur Wikipedia qui a codé Git, ça ne vous étonnera pas.
• Avoir installé Git et être capable d’afficher sans erreur « git help ». L’installation n’a rien à voir avec notre sujet qui est de démystifier cet outil chamanique, pas de savoir comment le placer sur l’autel.

Dans ce premier tuto vous allez apprendre à :

• Créer un dépôt local.
• Enregistrer des modifications.
• Voir l’effet de ces modifications.
• Comprendre ce que fait exactement Git quand vous faites tout ça.

Temps de lecture : 1H30 minimum.

Créer un dépôt Git

Pour commencer, le plus simple est que nous travaillons tous avec les mêmes fichiers. Voici un petit Zip qui contient des fichiers texte, un dossier et une image pour nous permettre de faire nos tests :

tuto_git_evidence.zip

Téléchargez l’archive, faite une extraction et, depuis un shell, mettez vous dans le dossier ainsi obtenu. Si vous faites « ls » ou « dir », vous devriez maintenant voir :

tuto_git_e-vidence $ ls
divers  README.txt  README.txt~  TODO.txt  TODO.txt~  tuto.txt  tuto.txt~

Pour créer un dépôt local, ou « repository », nous allons utiliser « git init » :

$ git init
Initialized empty Git repository in ../tuto_git_e-vidence/.git/

Pour le moment, rien de compliqué. Techniquement, il semble qu’il ne s’est rien passé à part une petite phrase pour vous dire que Git a fait son boulot. Pourtant, si vous affichez les fichiers cachés, vous verrez qu’un nouveau dossier « .git » est apparu :

$ ls -a
.   divers  README.txt   TODO.txt   tuto.txt
..  .git    README.txt~  TODO.txt~  tuto.txt~

« .git » est le dossier qui contient tout l’historique de votre dépôt ainsi que tous ses fichiers de configuration. En gros, sauvegarder votre dépôt est aussi simple que de sauver ce dossier. Supprimer votre dépôt, c’est juste mettre ce dossier à la poubelle.

Inutile de passer du temps sur « .git ». Cachez le pour ne plus y penser.

Ah si, une dernière chose pour les anciens de SVN. « .git » n’existe que dans le dossier racine, à l’inverse des dossiers « .svn » qui se trouvaient dans chaque sous dossier. Cela rend la dissociation entre vos fichiers normaux et ceux stockés dans Git beaucoup plus simple.

A ce stade là, Git n’a absolument aucune trace d’aucun fichier. « git init » ne fait que créer le dépôt, il n’ajoute rien dedans. D’une manière générale, et c’est très important car constant avec Git, Git ne fera rien sans que vous lui demandiez explicitement. Cela semble souvent rébarbatif au début, mais cela vous donne un contrôle très fin sur ce que vous faites et paie sur le long terme.

Ajouter des fichiers au dépôt

Git possède un fonctionnement très particulier : il sauvegarde des listes de changements. Il ne se souvient pas de comment était les fichiers à un instant T, mais il se souvient de l’ensemble des modifications faites depuis le début.

C’est très déroutant au départ, surtout si l’on vient de SVN, car on raisonne en termes de versions de fichiers. Avec Git, il n’y a pas de versions de fichier. Il y a juste des groupes de changements à vos fichiers de départ. On appelle cela des « changesets ».

Au départ, dans votre historique, il n’y a rien. Pour Git, le premier « snapshot » (l’image du système de fichier qu’il garde en interne) est une feuille blanche. On dit alors à Git de prendre en compte des fichiers, et Git ne rajoute pas les fichiers mais « l’action d’avoir créé un fichier et son contenu ».

En pratique, voilà comment on ajoute nos fichiers :

$ git add README.txt         #1
$ git add TODO.txt
$ git add tuto.txt
$ git add divers                                           #2
$ git commit -m "Ceci est un commentaire"     #3
[master (root-commit) bbfc3cf] Ceci est un commentaire
 4 files changed, 5 insertions(+), 0 deletions(-)
 create mode 100755 README.txt
 create mode 100755 TODO.txt
 create mode 100644 divers/django.png
 create mode 100644 divers/truc_que_je_ne_classerai_jamais.txt
 create mode 100755 tuto.txt

Il y a beaucoup de choses à expliquer ici.

#1 : D’abord, on utilise « git add » pour signaler à Git que l’on veut ajouter cette modification au dépôt. J’ai bien dit « cette modification », pas « ce fichier », bien qu’on utilise le nom du fichier pour s’y référer. Ici on dit « ajoute la modification qui consiste à la création du fichier README.txt ».

#2 : On fait la même chose avec « TODO.txt » et « tuto.txt ». « git add » fonctionne de manière récursive, ce qui signifie que si vous lui donnez un dossier, Git va chercher toutes les modifications qu’il pourra trouver dans ce dossier, et ses sous-dossiers, ainsi que les sous-dossiers des sous-dossiers et ainsi de suite. Là, il s’aperçoit qu’il y a création de deux fichiers dans le sous dossier et il les ajoute.

#3 : Ensuite, on utilise « git commit » pour dire « sauvegarder ces modifications dans l’historique de Git ». Il est obligatoire d’écrire un commentaire à chaque commit, et on peut le faire entre autres en utilisant l’option « -m » suivie du commentaire entre guillemets.

Vous noterez d’une part que « git commit » est différent de celui utilisé par SVN. Commit sauvegarde les modifications dans le dépôt localement, pas du tout sur un serveur distant. Nous verrons comment sauvegarder les modifications sur un serveur distant plus tard.

Ensuite, du fait de l’aspect récursif de « git add », nous aurions pu faire « git add . » (”git add point”) à la racine pour ajouter toutes les modifications du dossier courant et donc de tout le projet, plutôt que de faire « git add nom_du_fichier » pour chaque fichier.

Certes, mais cela aurait eu un effet indésirable : celui d’ajouter également les fichiers temporaires « TODO.txt~ » et « README.txt~ ». C’est une des raisons pour laquelle la finesse de Git est agréable, vous pouvez contrôler exactement ce qui rentre et ce qui sort.

Tout de même, dans la plupart des cas, il est pratique de faire rapidement un « git add . ». Heureusement, Git fournit un moyen de déclarer une liste de fichiers que l’on ne souhaite jamais ajouter au dépôt : le fichier « .gitignore » (attention au point au début du nom).

« .gitignore » se place à la racine du dépôt, à côté du dossier « .git » (et non dedans). Il s’agit d’un fichier texte ordinaire mais caché, et sur chaque ligne vous pouvez mettre un nom de fichier que vous ne voulez jamais sauvegarder dans le dépôt. On peut utiliser l’étoile (*) comme joker.

Créez ce fichier (il n’existe pas par défaut), et ajoutez « *~ » sur la première ligne pour éviter la sauvegarde de tous ces fichiers temporaires.

Maintenant vous pouvez faire un « git add . » sans arrières pensées.

Comme « .gitignore » est un fichier ordinaire, il peut être ajouté au dépôt. Ce n’est pas obligatoire mais chaudement recommandé si vous souhaitez partager cette liste avec les autres développeur.

Donc :

$ git add .
$ git commit -m "Ajout du .gitignore"
[master e3bfc5d] Ajout du .gitignore
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

Jouons un peut avec les modifications

Modifions maintenant les fichiers. Supprimons le fichier « README.txt » (qui lit encore la doc de nos jours de toute façon ?), et ajoutons une ligne dans le « TODO.txt » qui devient :

- Maîtriser Git.
- Devenir un expert en Python.
- Créer mon premier site avec Django.
- Penser "ergonomie" dès le départ pour mon prochain dév.

On peut voir les modifications faites depuis le dernier commit grâce à la commande « git status » :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    README.txt
#	modified:   TODO.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Les utilisateur de SVN noterons que même si on utilise pas « git rm », Git comprend tout de même que le fichier a été supprimé.

Ajoutons un fichier « test.txt » (créez le normalement) :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    README.txt
#	modified:   TODO.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	test.txt
no changes added to commit (use "git add" and/or "git commit -a")

Deux grandes colonnes sont apparues. « Changed but not updated » correspond aux modifications effectuées sur des fichiers qui sont déjà pris en compte par Git. « Untracked files » liste les fichiers dont Git n’a encore jamais sauvegardé aucune modification.

Comme « git add » n’ajoute pas des fichiers, mais des modifications, on peut utiliser cette commande à la fois pour dire à Git de prendre en compte la création de « test.txt », mais aussi nos derniers changements :

$ git add .
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   TODO.txt
#	new file:   test.txt
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    README.txt
#

« Changes to be committed » contient maintenant la liste des changements qui seront sauvegardés si vous faites un commit. Si vous ne faites pas de commit, vous pouvez dire à Git de ne pas sauvegarder ces changement toute de suite.

Par exemple, vous ne voulez pas sauvegarde les changements faits sur « TODO.txt » immédiatement, dans ce cas vous pouvez faire « git reset » (nous verrons « reset » en détails dans un autre tuto) :

$ git reset HEAD TODO.txt
Unstaged changes after reset:
M	README.txt
M	TODO.txt

« TODO.txt » passent de la colonne « Changes to be committed » à « Changed but not updated » :

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   test.txt
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    README.txt
#	modified:   TODO.txt
#

Cette colonne contient tout ce que vous avez modifié mais que vous ne voulez pas encore sauvegarder. C’est exacte, vous pouvez très bien faire un commit qui ne sauvegarde que certaines modifications.

Vous noterez de plus que notre suppression de « README.txt » est bien détectée, mais pas ajoutée automatiquement pas le « git add » à la liste des choses à sauvegarder. C’est une protection pour vous éviter de bourrinement valider une suppression. Il faut la confirmer avec « git rm ». Contrairement à SVN, Git vous laisse utiliser « git rm » a posteriori sans tiquer :

$ git rm README.txt
rm 'README.txt'
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    README.txt
#	new file:   test.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   TODO.txt
#

Nous pouvons maintenant joyeusement sauvegarder nos modifications :

$ git commit -m "Ajout d'un fichier et suppression d'un autre"
[master 9f2f748] Ajout d'un fichier et suppression d'un autre
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100755 README.txt
 create mode 100644 test.txt

Le modification de « TODO.txt » n’a pas été sauvegardée par Git :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   TODO.txt
#

Vous pouvez voir l’historique des commits en utilisant la commande « git log » :

$ git log
commit 9f2f748ecb853a1cb616b6d387f7169dac32f243
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:12:18 2010 +0000
 
    Ajout d'un fichier et suppression d'un autre
 
commit e3bfc5d3457756d695bbed735ea018559d8b00cd
Author: ksamuel < mail@e-vidence.net>
Date:   Sat Mar 27 18:52:12 2010 +0000
 
    Ajout du .gitignore
 
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel < mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire

Le log permet de voir rapidement le nombre de commit, la date, et l’auteur des modifications. C’est un aperçu de l’historique de Git. On voit ici toute la valeur des commentaires qui permettent de comprendre rapidement de quoi il est question.

Il est possible de change son nom, son email, et aussi la manière dont s’affiche le log, mais ce sera pour plus tard.

Pour les utilisateur de GNU/Linux, sachez que vous avez la commande « tig » qui vous permet de naviguer très facilement dans le log. Sous Ubuntu, installer « tig » est un simple « apt-get ».

Finalement, ajoutons les modifications faites à « TODO.txt » :

$ git add TODO.txt
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   TODO.txt
#
$ git commit -m "Finalement le TODO est bien comme ça"
[master edfb9d2] Finalement le TODO est bien comme ça
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git log
commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:19:33 2010 +0000
 
    Finalement le TODO est bien comme ça
 
commit 9f2f748ecb853a1cb616b6d387f7169dac32f243
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:12:18 2010 +0000
 
    Ajout d'un fichier et suppression d'un autre
 
commit e3bfc5d3457756d695bbed735ea018559d8b00cd
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:52:12 2010 +0000
 
    Ajout du .gitignore
 
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire

Dense n’est-ce pas ? C’est sans doute le plus gros défaut de Git : la masse d’informations qu’il vous demande de gérer en plus au début. Une fois qu’on maîtrise le concept, ce n’est plus un problème car ces informations font partie de votre work flow, mais au début c’est un poids en plus, et il faudra patienter un peu avec que cela devienne naturel.

Encore une fois par rapport à SVN vous noterez les différences suivantes :

• Git vous oblige à une étape intermédiaire entre vos modifications et la sauvegarde : vous devez sélectionner explicitement ce que vous voulez sauvegarder. Le bon côté, c’est que vous pouvez facilement sauvegarder des modifications et pas d’autres. Le côté ennuyeux, c’est que c’est une étape qu’on ne peut pas sauter.
• Git vous permet de supprimer les fichiers sans paniquer.
• Le commit de Git sauvegarde les modifications en local, pas sur un serveur distant. Vous pouvez le faire au milieu du désert si vous le souhaitez.

Comprendre ce qui vient de se passer

Vous avez fait 4 commit, et il y a donc maintenant 4 « changesets » dans l’historique de votre dépôt.

Vous pouvez voir ces changesets avec « git log », le plus récent étant le premier affiché. :

$ git log
commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:19:33 2010 +0000
 
    Finalement le TODO est bien comme ça
 
commit 9f2f748ecb853a1cb616b6d387f7169dac32f243
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:12:18 2010 +0000
 
    Ajout d'un fichier et suppression d'un autre
 
commit e3bfc5d3457756d695bbed735ea018559d8b00cd
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:52:12 2010 +0000
 
    Ajout du .gitignore
 
commit bbfc3cf5ef3f93c4aab17b39193907a047b5617b
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 18:34:49 2010 +0000
 
    Ceci est un commentaire

Vous noterez la ligne « commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231 ». Le code étrange à côté du mot « commit » est “le nom” du changeset, son identifiant unique, aussi appelé « hash ». Si vous voulez vous référer à un changeset en particulier, notez ce hasg (il est différent pour vous et moi car nous n’avons pas le même dépôt).

Vous pouvez voir quelle est la différence entre un changeset et un autre avec « git diff », et cette commande attend le hash d’un autre changeset. Par exemple, pour voir quel sont les différences entre ce qu’il y a maintenant dans notre projet et ce qu’il y avait dans le commit « Ajout d’un fichier et suppression d’un autre » :

$ git diff  9f2f748ecb853a1cb616b6d387f7169dac32f243
diff --git a/TODO.txt b/TODO.txt
index 664dc6b..a85daaf 100755
--- a/TODO.txt
+++ b/TODO.txt
@@ -1,3 +1,4 @@
+- Maîtriser Git.
 - Devenir un expert en Python.
 - Créer mon premier site avec Django.
 - Penser "ergonomie" dès le départ pour mon prochain dév.

Pour déchiffrer ce message, il faut le couper en deux :

diff --git a/TODO.txt b/TODO.txt
index 664dc6b..a85daaf 100755
--- a/TODO.txt
+++ b/TODO.txt
@@ -1,3 +1,4 @@

Indique de quoi on va parler. Ici, il que l’on va voir les modification apportées à « TODO.txt ». Ensuite :

+- Maîtriser Git.
- Devenir un expert en Python.
- Créer mon premier site avec Django.
- Penser "ergonomie" dès le départ pour mon prochain dév.

Est le contenu du fichier lui-même, annoté pour montrer où se situent les ajouts (+) et les retraits (-). Ici c’est un peut confus car mes lignes commences déjà par « - » Il existe par ailleurs des moyens plus confortables de voir les différences et les status, mais ce n’est pas l’objet du jour.

Ok, on voit ce qui s’est passé dans notre projet, mais comment Git voit-il tout cela ? Réponse en schémas :

Comme vous le voyez, chaque changeset n’est pas indépendant, mais pointe vers un autre et le sens de la flèche est contre intuitif.

On pourrait penser que la flèche pointe vers le changeset suivant, en fait, pas du tout : chaque changeset pointe vers son « parent », c’est à dire le changeset précédent. En effet, il applique des modifications sur son parent.

On peut donc lire le diagramme ci-dessus comme :

« Finalement le TODO est bien comme ça » est une série de modification sur « Ajout d’un fichier et suppression d’un autre » qui est une série de modifications sur « Ajout du .gitignore » qui est une série de modifications sur « Ceci est un commentaire ».

Git conserve un historique de modifications, et l’unité est un groupe de modifications. Utiliser Git, ce n’est rien d’autre dire où l’on se trouve dans l’historique. En clair, contrairement à SVN, on ne dit pas «j’ai tels fichiers à ma disposition maintenant » mais, « je me trouve à tel changeset dans l’historique ».

Cela signifie qu’il y a dans Git, en permanence, un pointeur pour dire où vous êtes. L’historique ne bouge pas, c’est vous qui bougez !

Ce pointeur, Git l’appelle « HEAD », et ce n’est ni plus ni moins qu’un qu’un gros panneau qui vous dit « vous êtes ici » :

« HEAD » ne contient rien. « HEAD » est juste un marqueur pour vous indiquez votre position dans l’historique. Quand plus tard vous apprendrez à revenir en arrière, l’historique ne bougera pas, c’est vous qui bougerez :

Ne pas confondre Index, HEAD et la copie de travail

Les schémas que vous venez de voir sont incomplets, car Git possède une grande subtilité qu’il faut absolument comprendre pour pouvoir l’utiliser : vous ne travaillez jamais sur « HEAD ».

« HEAD » est le marqueur qui vous indique où vous vous trouvez dans l’historique, il serait donc normal de penser que c’est là où l’on travail. Pas du tout.

« HEAD » pointe sur le dernier changeset, qui est une copie immuable et on ne peut pas la modifier.

Mais alors, dans quoi travaille-t-on ?

Et bien Git ajoute deux notions supplémentaires :

• la copie de travail;
• l’index.

La copie de travail, c’est votre projet tel que vous pouvez le voir. Ce sont les fichiers que vous modifiez, supprimez, ajoutez. Ces fichiers ne sont pas sauvegardés dans Git. Ce sont des fichiers normaux, et si vous faites une modifications sur un fichier puis que vous le supprimez avant de faire un commit, les modifications seront perdues.

En clair, vous travaillez toujours en dehors de Git.

Git ne vous permet pas de travailler dans son historique, il vous permet juste :

• d’ajouter des modifications;
• de récupérer des modifications;
• de vous déplacer dans les modifications.

Un changeset ne se modifie pas (en tout cas, pas comme vous le pensez), et on à jamais accès directement à « HEAD ». « HEAD » pointe sur un changeset, qui est une boîte, un coffre fort qui contient et protège les dernières modifications enregistrées.

Mais alors pourquoi mettre un panneau « vous êtes ici » si vous n’êtes pas vraiment ici ? Et bien vous êtes ici au sens Git du terme, c’est à dire que c’est ici, sur ce changeset, que se rajoutera votre prochain commit.

Nous avons donc deux choses importantes :

• L’historique : une liste de changesets dans laquelle on peut se promener mais qu’on ne peut pas modifier. On peut juste lui rajouter un nouveau changeset.
• La copie de travail : votre projet, des fichiers normaux, modifiables, et complètement en dehors de Git.

Mais alors, à quoi sert l’index ?

Il s’agit tout simplement de l’étape qui vous permet de faire passer vos modifications hors de Git, dans Git.

L’index, ce changeset mal connu

Concentrez vous bien sur cette partie parce que c’est la notion qu’il manque à la plupart des utilisateurs de Git en péril. Si vous comprenez ça, la suite sera facile.

L’index est un changeset, au même titre que tous les autres, mais il a deux particularités :

• Il est modifiable par les commandes « add », « rm » et « reset »;
• Il n’est pas inclus dans l’historique Git.

L’index est juste une étape intermédiaire qui vous permet de dire, « voilà à quoi doit ressembler mon prochain changeset dans l’historique si je fais un commit ». C’est un outil qu’on peut modifier à loisir, remettre à zéro, casser, reconstruire, démolir, etc.

Voici donc un schéma plus complet du fonctionnement de Git :

A chaque commit, l’index est sauvegardé par dessus le changeset sur lequel pointe « HEAD », puis « HEAD » est déplacé sur le nouveau changeset :

Un peu de pratique

Modifiez TODO.TXT pour qu’il ressemble à ceci :

- Maîtriser Git.
- Mettre un commentaire sur ce tuto parce qu'il est pas mal quand même.
- Devenir un expert en Python.
- Créer mon premier site avec Django.
- Penser "ergonomie" dès le départ pour mon prochain dév.

Supprimez aussi le fichier « tuto.txt ».

Vous allez voir « git status » d’un nouvel oeil :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   TODO.txt
#	deleted:    tuto.txt
#

« Changed but not updated » veut dire « changé dans la copie de travail mais pas dans l’index ». En gros, vous avez modifié des fichiers, mais vous n’avez pas ajouté ces modifications dans l’index. Ce que l’on fait avec « git add/rm » :

$ git add TODO.txt
$ git rm  tuto.txt
rm 'tuto.txt'
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   TODO.txt
#	deleted:    tuto.txt
#

« Changes to be committed » veut dire, « ces modification sont dans l’index, elles seront sauvegardées au prochain commit ». On peut choisir qu’une de ces modifications ne soit pas appliquée :

$ git reset HEAD TODO.txt
Unstaged changes after reset:
M	TODO.txt

« git reset » remplace la modification de « TODO.txt » de l’index par l’état de « TODO.txt » qui se trouvait dans « HEAD ».

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    tuto.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   TODO.txt
#

Pour l’instant, rien n’est sauvegardé :

$ git log
commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:19:33 2010 +0000
 
    Finalement le TODO est bien comme ça
[…]

On commit :

$ git commit -m "On sauvegarde l'index dans l'historique"
[master 1a0633c] On sauvegarde l'index dans l'historique
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100755 tuto.txt

Les modifications de l’index sont maintenant dans l’historique et « HEAD » pointe dessus :

$ git log
commit 1a0633ce778044aadea23eb39cdc21fc6c949989
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 21:08:04 2010 +0000
 
    On sauvegarde l'index dans l'historique
 
commit edfb9d255b7a77b7babeaeda3ea6630b38ca1231
Author: ksamuel <mail@e-vidence.net>
Date:   Sat Mar 27 19:19:33 2010 +0000
 
    Finalement le TODO est bien comme ça
[…]

Git est complexe mais pas compliqué

Si vous avez bien suivi le tuto, vous devriez maintenant comprendre, non seulement le principe de modifier / sauvegarder, mais aussi ce que fait Git derrière quand vous lui demandez de telles actions.

Ce n’est pas difficile à comprendre, mais c’est beaucoup d’informations à retenir comme en témoigne ce long tuto. Malgré cela, les explications que l’on trouve sur le net sont généralement très incomplètes ou nébuleuses, et j’espère donc que cet article vous aura réconcilié avec ce merveilleux outil qu’est Git.

Dans le prochain tuto, nous verrons comment revenir en arrière avec Git quand on a fait des modifications qui ne nous plaisent pas à l’aide des commande « checkout » et « reset ».

« self » est une variable ordinaire

« self » n’est pas un mot réservé en Python. C’est une variable ordinaire. Elle n’a rien de spéciale. Rien. De fait elle n’existe pas par défaut, et si vous essayez de l’afficher sans l’avoir déclaré vous aurez une erreur:

>>> print(self)
 
NameError: name 'self' is not defined
 
>>> print(toto)
 
NameError: name 'toto' is not defined

Vous noterez que l’erreur n’est pas « Used ’self’ outside of a class » ou autre. C’est une banale erreur de déclaration. Et vous pouvez très bien mettre n’importe quoi dans « self »:

>>> self = "e-vidence.net"
>>> print(self)
e-vidence.net

En fait, l’usage de « self » est purement une convention. En Python vous écrivez :

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(self):
...        return self.eggs
…
>>> o = Ornithorynque()
>>> o.pondre()
3

Mais ce n’est pas du tout une obligation. Vous pouvez utiliser n’importe quel nom de variable en lieu et place de « self ». Vous préférez « this » :

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(this):
...        return this.eggs
…
>>> o = Ornithorynque()
>>> o.pondre()
3

Ça marche très bien. Vous vous sentez d’humeur taquine, voir carrément mégalo?

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(MOOOOI):
...        return MOOOOI.eggs
…
>>> o = Ornithorynque()
>>> o.pondre()
3

Ça marche également. La raison à cela est très simple : Python se fiche complètement de « self ». « self » n’est pas du tout le centre du problème, Python ne fonctionne pas comme les autres langages, en attribuant à une variable locale la référence à l’instance courante.

Pourtant, tout le monde utilise « self », et ce par pure convention. En effet, si tous les codeurs utilisent la même notation, on sait de quoi on parle. Ainsi, n’utilisez jamais autre chose que « self », tout ce que vous gagneriez serait un surplus de complexité. La plupart des outils de coloration syntaxique pour Python supposent que « self » est l’instance en cours.

Si c’est un choix collectif, pourquoi avoir choisi « self » et non « this », qui semble plus commun ? La raison est simple, Python s’inspire du langage Smalltalk-80, qui utilise aussi « self ». C++ est sorti la même année, en 1980, et utilisait « this ». Il n’y avait donc pas de choix « le plus populaire » à l’époque et on utilisait les conventions de son modèle. Ainsi, Java et PHP s’inspirant du C++, utilisent « this ».

Il y a une grosse différence cependant : Java et PHP attribuent automatiquement cette valeur à « this ». Pyhon se fiche complètement de « self », qui n’est qu’une conséquence d’un mécanisme plus important : le passage automatique d’une référence à l’instance en cours à toutes les méthodes de cette instance.

Comment « self » arrive dans votre méthode

« Self » est une variable ordinaire, et la raison pour laquelle on ne peut y accéder que dans une méthode et donc la même que pour toute variable : vous ne la déclarez que dans les méthodes, et donc son scope est limité au bloc dans lequel vous la déclarez.

Vous seul déclarez « self ». Vous êtes la seule raison pour laquelle « self » est là. Et vous pouvez très bien ne pas déclarer self :

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(*selfless):
...        return selfless[0].eggs
...
>>> o = Ornithorynque()
>>> o.pondre()
3

Ce que vous ne pouvez pas faire en revanche, c’est déclarer une méthode sans aucun paramètre :

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre():
...        return 3
...
>>> o = Ornithorynque()
>>> o.pondre()
 
TypeError: pondre() takes no arguments (1 given)

Vous notez que l’erreur n’est pas « self is missing » mais quelque chose de plus simple, plus générique. Vous avez déclaré une méthode et cela marche parfaitement. C’est à l’utilisation que ça plante, on vous dit que votre méthode n’attend aucun argument, mais que pourtant on lui en a passé un. C’est une erreur très courante, qui n’a rien à voir avec la programmation orientée objet :

>>> def dis_bonjour():
...     print("bonjour")
...     
>>> dis_bonjour()
bonjour
>>> dis_bonjour("argument_bidon")
 
TypeError: dis_bonjour() takes no arguments (1 given)

Nous touchons ici le coeur du problème : Python ne créé pas automatiquement une variable qui contient une référence à l’instance en cours, il passe automatiquement l’instance en cours comme premier paramètre de toutes les méthodes de cette instance. A votre charge de récupérer cette référence dans la variable de votre choix.

C’est pour cela que l’on doit mettre « self » comme premier paramètre des toutes les méthodes : pour récupérer la référence que Python passe automatiquement. « Self » n’a rien de spécial, c’est un paramètre normal que vous créez, ce qui est spécial c’est que Python passe automatiquement au moins un paramètre à toutes les méthodes, même si on ne lui demande rien.

C’est une décision architecturale, une des philosophies de Python est « explicit is better than implicit », c’est à dire qu’il vaut mieux dire clairement ce qu’on veut plutôt que compter sur un sous-entendu. Quand vous êtes en Java, vous pouvez ne pas mettre « this », et dans la plupart des cas cela marchera car il est sous-entendu. En Python on ne peut pas : on doit dire ceci est l’instance, je la prend là, je la met là, et là je change son attribut.

Vous allez me dire, « ok, mais on aurait pu rendre explicite cette manipulation sans obliger à déclarer la variable ». C’est vrai après tout, cela aurait été plus automatique, et Python n’est-il pas là pour vous aider à économiser du temps en automatisant ce qui peut l’être ? C’est un point valide, et je ne suis pas Guido pour trouver une réponse pertinente, mais je peux vous présenter les côtés intéressants de cette fonctionnalité. Car s’en est une.

Jouons un peu avec et sans « self »

Python passe automatiquement l’instance de l’objet en cours si vous utilisez cette méthode depuis un objet.

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(self):
...        return self.eggs
...
>>> o = Ornithorynque()
>>> o.pondre() # 'o' est un objet de type  Ornithorynque, python passe donc 'self' à 'pondre'

Mais on peut aussi passer cette instance manuellement ! Il suffit d’appeler la méthode à partir de la classe, et non d’un objet :

>>> orni = Ornithorynque()
>>> orni.eggs = 2
>>> Ornithorynque.pondre(orni) # Python ne passe pas de référence car on appel « pondre » depuis la classe
2

Ici on créé notre propre référence, et on la passe. C’est cette référence qui sera utilisée par la méthode « pondre », puisque c’est le premier paramètre, et que le premier paramètre est « self ».

Python est un langage qui vous laissent aller très loin dans l’introspection. Cette fonctionnalité en fait partie, et on peut lui trouver des usages très tordus. Imaginez par exemple qu’on peut récupérer des instances par paramétrages dynamique, et inclure ou non l’instance en cours :

>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(*args, **kwargs):
...        return tuple(orni.eggs for orni in args)
...
>>> o = Ornithorynque()
>>> o.eggs = 23
>>> o.pondre(Ornithorynque(), Ornithorynque(), Ornithorynque()) # l'instance en cours est dans le lot
(23, 3, 3, 3)
>>> Ornithorynque.pondre(Ornithorynque(), Ornithorynque(), Ornithorynque())
(3, 3, 3)

Une application concrète ? Ok, je n’en ai aucune, mais c’est super marrant non ?

Python est un langage très souple, il vous encourage largement au duck typing et rien ne vous empêche de prendre des morceaux de code qui n’ont rien à voir et d’en faire un tout cohérent :

>>> def voler(animal) :
…    return '%s voooooooole' % animal
...

Cette fonction, merci à Python, peut accepter des paramètres très variés :

>>> print(voler(Ornithorynque()))
<__main__.Ornithorynque object at 0xb74cc7ac> voooooooole
>>> print(voler('Je'))
Je voooooooole
>>> class Ornithorynque(object):
...
...    eggs = 3
...
...    def pondre(*args, **kwargs):
...        return tuple(orni.eggs for orni in args)
...
…   def __str__(self):
…       return 'Orni'
…
>>> print(voler(Ornithorynque()))
Orni voooooooole

On peut très bien vous avoir donné cette fonction, par exemple dans une bibliothèque généraliste sur la lévitation qui ne connait rien aux ornithorynques. Tout développeur agile avec un peu d’expérience vous dira que c’est très crédible comme scenario

Maintenant, vous voulez écrire une méthode similaire pour votre cher mammifère ovipare. C’est inutile, hop, un petit cout de colle et vous rajoutez à ce bec de canard et cette queue de castor des ailes de cygne :

>>> Ornithorynque.voler = voler
>>> o = Ornithorynque()
>>> o.voler()
'Orni voooooooole'

La fonction « voler » accepte un argument qui doit être une instance de quelque chose. Si vous attachez cette fonction à la classe ‘Ornithorynque’, appeler « o.voler » implique que Python passe automatiquement l’instance en cours à cette fonction comme premier paramètre. Donc ça marche tout seul.

Notez que contrairement à Javascript, ça ne marche pas sur les built-ins :

>>> int.voler = voler
 
TypeError: can't set attributes of built-in/extension type 'int'

Ce qui est bien dommage car j’entrevois des applications titanesques dans le transport aérien si les ‘integers’ pouvaient voler à côté des ‘platipus’. Mais passons.

Sachez que Python est un langage qui s’étale en profondeur plus qu’en largeur. A chaque fois, c’est simple au début, mais si vous creusez vous verrez qu’il y a de nombreuses possibilités dont vous n’aviez même pas idée.

Aviez vous déjà pensé que tout est objet. Donc les fonctions sont des objets. Les classes sont des objets. Et qu’il peuvent être passés à la place de l’instance en cours…

Ça ouvre des perspectives non ?

D’ailleurs Python lui-même utilise déjà des petites astuces de ce genre. Par exemple il n’existe pas de méthodes statiques. Mais si vous voulez quelque chose similaire, vous pouvez utiliser le décorateur « classmethod ». En fait, cette méthode statique n’est qu’une méthode normale à laquelle on passe une référence à la classe en cours plutôt qu’une instance de l’objet en cours.

>>> class Ornithorynque(object):
...
...    eggs = 3
…
…   def __init__():
…      self.eggs = 4
…
…   @classmethod
...    def pondre(cls): # la convention ici passe de 'self' à 'cls' pour éviter la confusion
...        return cls.eggs
...
>>> print(Ornithorynque.pondre())
3

Malheureusement, même Python pose des limites et on ne peut pas définir de « self » par default. « self » n’est pas en cause, c’est une variable ordinaire. Mais Python surveille le premier paramètre d’une méthode pour voir si il correspond au même type que l’objet qu’il doit traiter :

>>> class SuperFile(file):
…     
…     def __init__(*args, **kwargs): # un peut de magie ici pour hériter de file
…         file.__init__(*args, **kwargs)
...
…     def super_write(self=sys.stdout, txt=''): # un 'self' par default qui écrit sur stdout
…         self.write(txt.upper())
…         
>>> sf = SuperFile("woooot.txt", "w")
>>> SuperFile.super_write(txt="J'aime les pythons et les ornitorynques")
 
TypeError: unbound method super_write() must be called with SuperFile instance as first argument (got nothing instead)

Dommage… Mais peut être que je suis tordu ?

Question de représentation

Prenons un animal au hasard. L’hirondelle d’Afrique par exemple. Ou d’Europe. A vide en tout cas. Bon ça devient trop compliqué, prenons un chien.

Le mot « chien », représente l’animal quadrupède et cabochard que nous apprécions tous (ou pas). « Chien », est une représentation de l’animal, pas l’animal lui-même. Encore heureux, un chien n’est pas une série de caractères alignés, c’est un organisme complet avec poils, bave et toutes ces joyeusetés. Mais pour nous permettre de communiquer entre nous, de garder trace aussi en écrivant sur papier et informatiquement, nous utilisons le mot « chien ».

« Chien » est une représentation, et il en existe d’autres. Les anglais utilisent « dog », les espagnols utilisent « perro ». On parle du même truc qui aboie et mange trop de croquettes, mais on utilise une représentation différente, composée de symboles textuels : les mots.

Un autre exemple souvent cité, celui des chiffres. On utilise « 5 » pour représenter le concept de cinq, mais les romains utilisaient « V ». On parle de la même chose, la donnée est la valeur de cinq, mais sa représentation peut être « 5 », « V », « cinq », « five », « cinco », etc.

C’est un concept très important en informatique : la représentation est différente de la donnée. Par exemple quand vous faites :

>>> age = 5

Python ne stocke pas 5, car l’ordinateur ne connait que des zéros et des uns. Il stocke quelque chose qui ressemble à sa représentation binaire : « 101 ». On parle de la même chose, le concept du « nombre 5 », mais Python et votre esprit le représentez différemment.

Et bien pour le chaîne de caractère, c’est pareil. Si vous faites :

nom = 'e-vidence'

Python ne stocke par la chaîne ‘e-vidence’ mais sa représentation. Chaque lettre est traduite en un nombre, qui lui, est gardé en mémoire.

Là où ça se gâte, c’est pour savoir : à quel nombre correspond quelle lettre ?

Et ça, ça dépend de l’encodage utilisé. L’encodage, c’est un énorme tableau qui dit à quelle lettre correspond quel nombre. Il y a beaucoup d’encodages différents. Beaucoup, beaucoup. La plupart ne permettent pas de représenter toutes les lettres, car il existent des caractères spéciaux dans toutes les langues : chinois, suédois, russe…

Votre système d’exploitation (Windows, Mac, Linux, etc) lit et écrit en utilisant un encodage. Python également. Toute donnée texte est écrite en utilisant un encodage, et on ne peut lire ce texte que si on connait son encodage d’origine.

En gros, si pendant des années vous avez manipulé des textes avec Python sans connaître leur encodage d’origine, c’est parce que vous avez eu de la chance. Si, si, c’est un coup de moule, promis.

Les encodages, du plus simple au plus complexe

Le plus simple des encodage est l’encodage ASCII. Inventé par les américains, il contient 128 caractères, dont une centaine sont visibles :

>>> import string
>>> print(string.printable)
'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|}~ \t\n\r\x0b\x0c'
>>> print(len(string.printable))
100

Ces caractères vous sont familiers ? En Europe, on les retrouve partout, et c’est une des raisons pour laquelle on ignore souvent les problèmes d’encodage : ASCII suffit à de très nombreux usages dans nos pays. En fait, tant que vous n’utilisez pas « é » ou «ç » et autres exotismes, tout ira bien car ASCII est souvent contenu dans la plupart des autres encodages.

Seulement viendra le moment où vous devrez traiter un texte français correctement écris. Viendra le moment où vous traiterez un texte espagnol, et tous ces vilains « ~ », et, en bidouillant, vous vous en sortirez. Et un matin, vous codez un projet open source avec un coréen et vous êtes forcés de chercher à comprendre.

D’abord, il faut savoir que chaque langue ou presque à son tableau de correspondant « lettre - nombre ». Le plus utilisé en Europe est l’encodage « ISO-8859-1 », qui permet de traduire en nombre tous les caractères ASCII, mais aussi les accents, les cédilles, les tildes et tout le toutim. Windows utilise un encodage quasiment similaire appelé « CP-1252 ».

Mais que se passe-t-il si vous recevez un texte en chinois, encodé par exemple avec « GB2312 » ? Et bien vous recevez des nombres qui correspondent à des caractères chinois. Si le programme sait que le texte est chinois et qu’il a accès à un encodage chinois, il pourra traduire chaque chiffre en caractère.

Dans le cas contraire, le programme essayera de transformer les chiffres en utilisant votre encodage, souvent ISO-8859, ce qui vous donnera soit des lettres incohérentes, soit un gros plantage car il y a bien plus de caractères en chinois que de lettres en français et certains nombres n’apparaissent donc pas dans ISO-8859.

Pour pouvoir lire un texte, quel qu’il soit (page Web, email, fichier texte, XML, nom de fichier, titre de MP3, etc), il faut savoir dans quel encodage il est écrit et avoir cet encodage sous la main. Si ça marche sans cela, c’est simplement que par chance le texte est écrit dans l’encodage par défaut de votre système.

De plus, pas besoin de chercher un exemple tordu à base de correspondances asiatiques pour avoir des problèmes d’encodage. Un simple lecteur de musique peut afficher « Les chants de Noël » avec une orthographe des plus farfelus, simplement parce que la personne qui a enregistré la chanson la fait depuis un autre système.

Vu le nombre de langues et de caractères spéciaux, il a été créé un encodage qui permet de traduire tous les caractères : « unicode ». Unicode possède des sous ensembles tel que UTF-8 et UTF-16, et nous allons essentiellement utiliser UTF-8 dans cet article car c’est le plus rependu.

Unicode résout donc en théorie la plupart des problèmes, mais en pratique des milliers d’applications utilisent encore des encodages locaux. Il va falloir faire avec.

Gérer tout ce boxon avec Python

Pour Python, il nous faut nous soucier de trois couches : l’encodage du système d’exploitation, l’encodage du fichier du script Python et l’encodage de Python. Pour se simplifier les choses, mettez tout en unicode.

Écrivez votre script Python en UTF-8, et pour cela, réglez votre éditeur de texte sur UTF-8 dans ses préférences. Rajoutez ensuite la ligne suivant en première ligne de tous vos script :

# -*- coding= UTF-8 -*-

Cela précise à Python que c’est écrit en UTF-8. Sans cette mention, la moindre apparition d’un « é » déclenchera l’erreur « SyntaxError: Non-ASCII character ». ASCII est en effet l’encodage par défaut de Python.

Enfin, écrivez vos chaînes en les préfixant de ‘u’ :

>>> comment = u'De façon évidente'

Ce ‘u’ force ce Python à créer une chaîne encodée en UTF-8.

Maintenant, tout ce que vous avez à l’intérieur de votre programme est en UTF-8, vous ne pouvez plus avoir de problèmes d’encodage sans entrée ou sortie de données. Mais un programme qui reste fermé sur lui-même est rarement très utile, il va donc falloir apprendre à traduire depuis et vers UTF-8.

Quand vous lisez un fichiez, vous faites ainsi :

>>> fichier = open("fichier.txt")
>>> for ligne in fichier :
… print(ligne)
…

Lire un fichier est une entrée de données. Si le fichier est écrit dans votre encodage, vous n’aurez pas de problème. Typiquement, si vous êtes sous Windows et que vous lisez un fichier écrit par Windows, il sera en ASCII ou ISO-8859, et tout ira bien. Mais si vous recevez un fichier issu d’un Mac, il sera probablement en UTF-8, et alors votre programme affichera des caractères étranges ou plantera.

Le meilleur moyen de prévenir cela est de décoder la donnée ainsi lue. Python fournit aux chaîne les méthodes « encode » et « decode », qui convertissent les données depuis et vers UTF-8 :

>>> fichier = open("fichier.txt")
>>> for ligne in fichier :
… ligne_decodee = ligne.decode("UTF-8")
… print(ligne_decodee)

Là vous allez me dire, « mais pourquoi on décode un fichier en UTF-8 vers de l’UTF-8 ? ». Tout simplement parce que Python ne sait pas que le fichier est en UTF-8. Il n’a aucun moyen de le savoir. Et comme son encodage par défaut n’est pas UTF-8, il va enregistrer ces chaines en mémoires dans son encodage par défaut au lieu du bon.

A l’inverse, si vous êtes sous Linux, et que vous voulez lire un fichier Windows :

>>> fichier = open("fichier.txt")
>>> for ligne in fichier :
… ligne_decodee = ligne.decode("CP-1252")
… print(ligne_decodee)

Ligne_décodee sera toujours de l’UTF-8, dans l’exemple 1 comme dans l’exemple 2, donc on sait ce qu’on traite.

Un moyen rapide de lire un fichier encodé dans un autre encodage est d’utiliser le module codecs :

>>> import codecs
>>> fichier = codecs.open("fichier.txt", "ISO-8859") # on donne l'encodage ici
>>> for ligne_decodee in fichier : # les lignes sont automatiquement décodées !
... print(ligne_decodee)

Pour certain d’entre vous

print(ligne_decodee)

affiche peut être des caractères bizarres, notamment si vous êtes sous Windows. C’est normal, votre système d’exploitation affiche dans la console avec son propre encodage. Non seulement il faut décoder les données en entrée, mais il faut aussi les réencoder à la sortie !

>>> fichier = open("fichier.txt")
>>> for ligne in fichier :
… ligne_decodee = ligne.decode("CP-1252")
… chaine_transformee = faire_quelque_chose_avec_les_chaines(ligne_decodee)
… print(chaine_transformee.encode('CP-1252'))

Ici, c’est un exemple avec un fichier, mais c’est valable pour toute donnée texte. Vous lisez un nom de fichier ? Il faut faut décoder et encoder. Vous téléchargez ou générez des pages Web ? Il faut décoder et encoder. Vous faites des requêtes à une base de données ? Il faut décoder et encoder.

En résumé: si des données rentrent qui ne sont pas de l’UTF-8, vous décodez. En interne, vous faites ce que vous voulez, tout est en UTF-8. Ensuite si des données sortent, vous encodez si le destinataire attend autre chose de l’UTF-8.

Pour vous donner une idée de l’importance du phénomène, voici le chemin d’une page Web et l’influence des encodages :

• Génération par un script Python écrit dans un encodage et stockant en mémoire les chaînes dans un encodage.
• Récupération de chaînes depuis la base de données qui stockent du texte dans un encodage qui peut être différent de l’encodage du texte lui-même.
• Création du HTML dans un encodage, et spécification d’un encodage dans la balise META.
  Envoie de la page par un serveur qui spécifie l’encodage dans le HEADER.
• Réception par le navigateur Web, codé dans un encodage, et réglé sur un encodage, installé sur un système qui possède son propre encodage.

Votre texte est en permanence décodé et encodé. Votre boulot est que au milieu de ce processus, votre script comprenne les données qui entrent, et les renvoient soit dans l’encodage d’origine, soit avec la mention du nouvel encodage.

Arrivé à ce stade, vous comprenez maintenant une chose : il est impossible de gérer cela correctement si on ne sait pas quel est l’encodage d’origine des données. On ne peut pas lire un livre si on ne sait pas dans quelle langue il est écrit, on ne peut pas écouter une émission de radio si on ne sait pas dans quelle langue elle est diffusée, et on ne peut pas manipuler un texte si on ne sait pas dans quel encodage il est représenté.

Comment déterminer l’encodage d’origine ?

Mauvaise nouvelle, il n’y a aucun moyen sûr de le faire, et c’est pour cela que parfois encore Firefox affiche de « � », et Outlook des « Ã© ». Mais on peut faire « au mieux ».

Faire au mieux c’est :

• Bien connaître les encodages qu’on utilise soi-même : votre serveur, vos textes, votre base de données… Vous devez parfaitement savoir comment ils stockent le texte. Dans le meilleurs des cas en UTF-8.
• Partir du principe que si les données extérieures communiquent un encodage, c’est le bon. Par exemple les pages Web déclarent l’encodage dans une balise meta :

  <meta http-equiv="content-type" content="text/html; charset=utf-8">

• Ne pas faire pour autant confiance à ces données extérieures pour autant et gérer les possibles erreurs de décodage :

  >>> try :
  …     u"é".decode("UTF-8")
  … except UnicodeEncodeError:
  …     print('Ça ne peut pas marcher !')
  …

• Dans le doute, on peut tenter de deviner l’encodage. Ce n’est pas très fiable, mais c’est mieux que rien.

En résumé, le seul moyen fiable de déterminer l’encodage d’origine est que le système à l’origine des données donne explicitement son nom. De votre côté, pour limiter les dégât, utilisez UTF-8 partout : base de données, serveur, page Web, etc.

u’Le mot de la fin’.encode(”ISO-8869-1″)

Ne devenez pas parano avec les encodages. Si vous développez un programme, mettez tout en UTF-8 et tout ira bien. Le jour où une erreur survient, ce sera à cause d’une donnée externe. Ce jour là, et ce jour là seulement, préoccupez vous de décoder et encoder ce flux de données qui entre et qui sort.

Sachez enfin que Python 3 gère maintenant par défaut toutes les chaînes en unicode, plus besoin de préfixer de ‘u’. Bien sûr, c’est loin d’être la version la plus utilisée.

Enfin, pour ne pas vous laisser sans un petit plus, voici un snippet que vous pouvez utiliser normaliser tous les caractères spéciaux qui ont un équivalent ASCII :

>>> import unicodedata
>>> s = u"éèêàùçÇ"
>>> print(unicodedata.normalize('NFKD', s).encode('ascii','ignore'))
eeeaucC

Iterables

Quand vous créez une liste, vous pouvez récupérer chacun de ses éléments un par un. On parle d’itération :

>>> maliste = [1, 2, 3]
>>> for i in maliste :
...    print(i)
1
2
3

Maliste est un iterable, en anglais cela signifie « que l’on peut itérer ». En Python, itérable est une caractéristique que n’importe quel objet peut avoir, il lui suffit de déclarer la méthode « __iter__() » ou « __getitem__ » :

>>> print(maliste.__iter__)
<method-wrapper '__iter__' of list object at 0xb73f648c>

Ainsi, les chaînes de caractères sont aussi des itérables :

>>> machaine = "e-vidence.net"
>>> print(machaine.__getitem__)
<method-wrapper '__getitem__' of str object at 0xb75005c0>
>>> for lettre in machaine:
...     print(lettre)
e
-
v
i
d
e
n
c
e
.
n
e
t

Les dicionnaires aussi sont des iterables :

>>> dico = {"site": "e-vidence", "langage": "python"}
>>> print(dico.__iter__)
<method-wrapper '__iter__' of dict object at 0x8bc7acc>
>>> for key in dico:
...     print(key)
...
langage
site

Bref, les iterables, c’est « les trucs sur lesquels on peut faire une boucle “for” ». Les tuples, les sets et les fichiers aussi ! Du coup quand vous utilisez « range() », vous créez une liste, donc un iterable. Et quand vous utilisez une liste en intention, vous créez une liste, donc un itérable.

>>> print(range(3))
[0, 1, 2]
>>> print([x*x for x in range(3)])
[0, 1, 4]
>>> ma_liste = [x*x for x in range(3)]
>>> for i in mylist :
...    print(i)
0
1
4

Les itérables sont très pratiques car ils se comportent tous pareils : on se fiche de savoir ce qu’il y a dedans, on sait qu’on peut prendre chaque élément un par un. Vous n’avez rien à faire, vous n’avez même pas besoin de savoir si il est plein, ou si il utilise « __iter__() » ou quoique ce soit. On utilise « for », et c’est tout ce qu’on a besoin de savoir.

Cependant les listes, tuples et autres ont un défaut, ils stockent toutes les valeurs en mémoire. Ce n’est pas forcément ce que vous voulez si vous avez énormément de valeurs à passer en revue.

Iterators

Les itérateurs sont des objets qui permettent d’utiliser les iterables. Normalement vous ne les voyez jamais, car ils sont automatiquement utilisés par Python de manière invisible. Vous pouvez très bien coder en Python sans jamais avoir besoin de savoir ce qu’est un itérateur. Connaître les itérateurs relève donc plutôt de la culture générale.

Quand un objet déclare la méthode « __iter__() », cette méthode retourne un itérateur :

>>> l = [1, 2, 3]
>>> iterateur = l.__iter__()
>>> print(iterateur)

On utilise généralement la function « iter() » pour éviter d’appeler directement « __iter__() » :

>>> l = [1, 2, 3]
>>> print(iter(l))

A quoi ça sert donc ? Et bien un itérateur possède une méthode « next() » qui permet d’avoir l’élément suivant de l’itérable dont il est issu. Quand il n’y a plus d’élément, il lève l’exception « StopIteration » :

>>> l = [1, 2, 3]
>>> iterateur = iter(l)
>>> print(iterateur.next())
1
>>> print(iterateur.next())
2
>>> print(iterateur.next())
3
>>> print(iterateur.next())
StopIteration

Cet objet, c’est ce que « for » utilise ! Quand vous utilisez « for », Python récupère automatiquement l’itérateur et appelle « next() ». D’ailleurs, « for » fonctionne sur les itérateurs :

>>> l = [1, 2, 3]
>>> iterateur = iter(l)
>>> for x in iterateur :
...     print x
...     
...     
1
2
3
>>> for x in iterateur :
... print x

Comme vous l’avez remarqué, on ne peut utiliser un itérateur qu’une seule fois. Une fois vidé, il reste vide.

Generators

Les générateurs sont des itérables, mais vous pouvez les lire une seule fois. C’est parcequ’ils ne gardent pas les valeurs en mémoire, mais les génèrent à la volée :

>>> mon_generateur = (x*x for x in range(3))
>>> for i in mon_generateur :
...    print(i)
0
1
4

C’est la même chose que l’exemple du début avec la liste en intention, mais au lieu d’utiliser « [] », on utilise « () ». La grosse différence, c’est qu’on ne pourra pas faire un « for » une deuxième fois sur « mon_generateur » car les générateurs ne peuvent être lus qu’une fois : ici il calcule 0, puis oublie la valeur et calcule 1, puis calcule 4. Une valeur à la fois.
L’avantage, c’est que « mon_generateur » consomme très peu de mémoire : aucune liste ne stocke toutes les valeurs.

Yield

« Yield » est un mot clé que l’on utilise exactement comme « return », sauf que la fonction va retourner un générateur :

>>> def creerGenerateur() :
...   maliste = range(3)
...    for i in maliste :
...        yield i*i
...
>>> mon_generateur = creerGenerateur() # créer le gérérateur
>>> print(mygenerator) # mon generateur est un objet !
>>> for i in mon_generateur:
...     print(i)
0
1
4

Ici, c’est un exemple inutile, mais c’est pratique si votre fonction retourne un très gros ensemble de données que l’on a besoin de lire une seule fois.

Pour bien comprendre « yield », il faut se rentrer dans la tête qu’à l’appel de la fonction le code de la fonction n’est pas éxécuté. C’est le piège : la function retourne un objet générateur et ne fait rien d’autre ! Ensuite, le code va s’exécuter à chaque fois que « for » utilise le générateur.

Maintenant la partie difficile (concentrez vous, lisez plusieurs fois) :

La première fois que le corps de la function va être exécuté, il va s’exécuter du début jusqu’à ce qu’il rencontre « yield », et il va retourner la première valeur de la boucle. Puis, à chaque nouvel appel, on va éxécuter la partie de la boucle une nouvelle fois, arriver à « yield », et retourner la nouvelle valeur. On va continuer ainsi jusqu’à ce qu’il n’y ai plus de valeur à retourner.

Un générateur est considéré comme vide une fois que la fonction s’exécute, mais ne rencontre plus « yield », quelle qu’en soit la raison : boucle vide, if / else, exception…

Oh, et pour les tatillons, un générateur est son propre itérateur :

>>> def creerGenerateur() :
...   maliste = range(3)
...    for i in maliste :
...        yield i*i
...     
>>> g = creerGenerateur()
>>> print(g == iter(g))
True
>>> g = creerGenerateur()
>>> print(g.next())
0

C’est bon, vous savez tout ce qu’il est nécessaire pour jouer avec les itérateurs et les générateurs, ainsi donc que « yield ». Pour les anglophiles, vous pouvez allez encore plus loin avec une passionnante présentations de Beazley sur des astuces à base de générateurs.

…
…
Toujours là ?
…
…

Bon encore un peu pour la route alors.

A ce stade là, vous avez du deviner à quoi sert « xrange() » : c’est l’équivalent de « range() », mais c’est un générateur (et un peu plus, car il possède son propre type) :

>>> print(range(3))
[0, 1, 2]
>>> print(type(xrange(3)))
<type 'xrange'>
>>> print(xrange(3))
xrange(3)
>>> print(list(xrange(3)))
[0, 1, 2]

Si vous vous sentez vaillant, jetez un coup d’oeil à cet exemple amusant de générateur :

>>> class Banque(): # créons une banque, qui fabrique des distributeurs
...    crise = False
...    def creer_distributeur(self) :
...        while not self.crise :
...            yield "100 €"
>>> bnp = Banque() # quand tout va bien, on a autant de monnaie que l'on veut
>>> distributeur_du_coin = bnp.creer_distributeur()
>>> print(distributeur_du_coin .next())
100 €
>>> print(distributeur_du_coin.next())
100 €
>>> print([distributeur_du_coin.next() for cash in range(5)])
['100 €', '100 €', '100 €', '100 €', '100 €']
>>> bnp.crise = True # la crise est là, plus de monaie
>>> print(distributeur_du_coin.next())
StopIteration
>>> distributeur_de_la_defense = bnp.creer_distributeur() # même pour les nouveaux
>>> print(distributeur_de_la_defense.next())
StopIteration
>>> bnp.crise = False # si la crise s'en va, les anciens distributeurs sont vides
>>> print(distributeur_du_coin.next())
StopIteration
>>> nouveau_distributeur = bnp.creer_distributeur() # mais les nouveaux sont pleins
>>> for cash in nouveau_distributeur :
...    print cash
100 €
100 €
100 €
100 €
100 €
100 €
100 €
100 €
100 €
...

Voilà qui peut être utile, par exemple pour gérer l’accès à une ressource.

Enfin, si vous travaillez beaucoup avec les itérateurs, faites connaissance avec le module « itertools » : dupliquer des générateurs, les chaîner, groupe des valeurs, utiliser « map() » et « zip() » sans créer une nouvelle liste… Une seule réponse : « import itertools »

Un exemple ? Voyons l’ordre d’arrivée possible d’une courses de 4 chevaux :

>>> chevaux = [1, 2, 3, 4]
>>> courses = itertools.permutations(chevaux)
>>> print(courses)
<itertools.permutations object at 0x8c2a77c>
>>> for resultat in courses:
...    print(resultat)
...
[(1, 2, 3, 4),
 (1, 2, 4, 3),
 (1, 3, 2, 4),
 (1, 3, 4, 2),
 (1, 4, 2, 3),
 (1, 4, 3, 2),
 (2, 1, 3, 4),
 (2, 1, 4, 3),
 (2, 3, 1, 4),
 (2, 3, 4, 1),
 (2, 4, 1, 3),
 (2, 4, 3, 1),
 (3, 1, 2, 4),
 (3, 1, 4, 2),
 (3, 2, 1, 4),
 (3, 2, 4, 1),
 (3, 4, 1, 2),
 (3, 4, 2, 1),
 (4, 1, 2, 3),
 (4, 1, 3, 2),
 (4, 2, 1, 3),
 (4, 2, 3, 1),
 (4, 3, 1, 2),
 (4, 3, 2, 1)]

Happy hacking

Ce que « * » ne permet pas de faire

Il n’y a pas de pointeurs en Python, et les passages par références sont automatiques. Du coup :

mon_objet = MaClasse()
mon_pointeur = *mon_objet
ma_valeur = **mon_pointeur

N’existe pas en Python. On ne peut pas récupérer un pointeur. On ne peut pas choisir si l’on passe une variable par valeur ou par référence. Tout est automatique et transparent.

Les usages basiques de « * »

La multiplication et la puissance fonctionnent comme on l’attend :

>>> print(2*3) # multiplier 2 par 3
6
>>> print(2**3) # élever 2 à la puissance 3
8

Mais déjà, Python se démarque du lot car l’opérateur * est surchargé par défaut, et peut s’appliquer aux chaînes de caractères et aux listes. Pour les chaîne, c’est simple :

>>> print("a" * 3) # on peut multiplier une chaîne par un nombre, et cela donne une chaîne
aaa
>>> print("a" ** 3) # ça ne marche pas avec les puissances
TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'

Pour les listes, c’est plus subtile. Une liste de nombre se multiplie sans y penser :

>>> l = [0, 1, 3]
>>> print(l * 2)
 # on peut multiplier une liste par un nombre, cela donne une liste
[0, 1, 3, 0, 1, 3]
>>> print(l ** 2)
 # ça ne marche pas avec les puissances
TypeError: unsupported operand type(s) for ** or pow(): 'list' and 'int'

En revanche, multiplier une liste d’objets modifiables ne fait que répéter la référence vers cet objet:

>>> l = [{}]
 # on fait une liste contenant un dictionnaire
>>> dicos = l * 3
 # on peut multiplier une liste par un nombre, cela donne une liste
>>> print(dicos)
[{}, {}, {}]

On a l’impression que le comportement est le même que précédemment, en fait pas du tout. Ici on a pas une liste de 3 dictionnaires, mais une liste de 3 références faire le même dictionnaire. Si on modifie le premier élément de la liste, tous sont modifiés :

>>> d = dicos[0] # on récupère ce qu'on croit être le premier dictionnaire
>>> d["Nouvelle cle"] = "Nouvelle valeur" # on le modifie
>>> print(dicos) # afficher la liste montre que les 3 dictionnaires sont en fait un seul et même objet
[{'Nouvelle cle': 'Nouvelle valeur'},
 {'Nouvelle cle': 'Nouvelle valeur'},
 {'Nouvelle cle': 'Nouvelle valeur'}]

Unpacking

Python intègre une fonctionnalité, l’unpacking, qui permet de prendre chaque élément d’une séquence et de les attribuer à des variables distinctes, d’un seul coup. C’est un raccourcis très partique :

>>> drapeau = ("bleu", "blanc", "rouge") # ici on utilise un tuple, mais ça marche avec les listes
>>> premiere_couleur = drapeau[0]
>>> deuxieme_couleur = drapeau[1]
>>> troisieme_couleur = drapeau[2]
>>> print(premiere_couleur)
'bleu'
>>> print(deuxieme_couleur)
'blanc'
>>> print(troisieme_couleur)
'rouge'
>>> couleur1, couleur2, couleur3 =  drapeau # la même opération, en une ligne grace à l'unpacking
>>> print(couleur1)
'bleu'
>>> print(couleur2)
'blanc'
>>> print(couleur3)
'rouge'

Vous n’avez rien à faire, l’unpacking est automatique : il suffit de mettre à gauche du signe « = » le même nombre de variables qu’il y a d’élément dans la séquence à droite du signe « = ». Dans le cas contraire, Python râle :

>>> un, deux = drapeau
ValueError: too many values to unpack
>>> un, deux, trois, quatre = drapeau
ValueError: need more than 3 values to unpack

Quel rapport avec « * » ? Et bien il permet de forcer l’unpacking dans le cas où c’est ambigüe. Faisons une petite fonction de test qui ne fait qu’afficher chacun de ses paramètres :

>>> def afficher_trois_elements(elem1, elem2=None, elem3=None):
...     print(elem1)
...     print(elem2)
...     print(elem3)
...
...
>>> afficher_trois_elements(drapeau)
('bleu', 'blanc', 'rouge')
None
None

Passer drapeau affiche logiquement le tuple comme premier paramètre, et ensuite les valeurs par défaut du premier et du second paramètre. En utilisant « * », nous pouvons forcer l’unpacking de telle sorte que les valeurs du tuple soient passées individuellement comme autant de paramètres :

>>> afficher_trois_elements(*drapeau)
bleu
blanc
rouge

Très pratique quand vous utiliser une collection tout au long du programme pour vous éviter de sans cesse trainer des variables intermédiaires. D’autant que ça marche combiné aux slices :

>>> l = [1, 2, 3, "element que l'on ne veut pas"]
>>> afficher_trois_elements(*l[:-1])
1
2
3

Encore mieux, on peut utiliser « ** » pour forcer l’unpacking des dictionnaires. Les valeurs du dictionnaires deviennent les valeurs des paramètres, mais cette association se fait par nom : chaque clé du dictionnaire doit correspondre à un nom de paramètre. Ainsi :

>>> elements = {"elem1" : "eau", "elem2" : "feu", "elem3" : "air"}
 # les clés ont le bon nom
>>> afficher_trois_elements(**elements)
eau
feu
air

Si une clé ne possède pas le nom adéquat, tout plante :

>>> elements = {"elem1" : "eau", "elem2" : "feu", "rien_a_voir" : "air"}
>>> afficher_trois_elements(**elements)
TypeError: afficher_trois_elements() got an unexpected keyword argument 'rien_a_voir'

Une autre erreur courante est d’utiliser « * » avec un dictionnaire. Dans ce cas l’unpacking fonctionne, mais comme itérer sur une dictionnaire donne une liste de clés, c’est comme si vous passiez une liste en paramètres contenant les clés :

>>> elements = {"elem1" : "eau", "elem2" : "feu", "elem3" : "air"}
>>> afficher_trois_elements(*elements)
elem2
elem3
elem1

Si vous donnez moins de valeurs qu’il n’y a de paramètres, Python remplit tout ce qu’il peut :

>>> afficher_trois_elements(*drapeau[:-1])
bleu
blanc
None
>>> elements = {"elem1" : "eau"}
>>> afficher_trois_elements(**elements)
eau
None
None

Dans le cas inverse – si i il y a plus d’élements que de paramètres – Python refuse les séquences, mais fait au mieux avec les dictionnaires :

>>> forces = ("rouge", "bleu", "jaune", "rose", "vert")
>>> afficher_trois_elements(*forces)
TypeError: afficher_trois_elements() takes at most 3 arguments (5 given)
>>> elements = {"elem1" : "eau", "elem2" : "feu", "elem3" : "air", "elem3" : "terre"}
>>> afficher_trois_elements(**elements)
eau
feu
terre

Paramétrage dynamique

Il est parfois pratique de définir une fonction qui accepte un nombre infini d’arguments. Par exemple, on a une fonction qui multiplie ses arguments entre eux :

>>> def multiply(a, b):
...     return a * b # attention, là on utilise « * » pour multiplier, ne cherchez rien de compliqué ;-)
...
>>> print(multiply(2, 3))
6

Bien sûr, si on veut rajouter un troisième paramètre, il faut la réécrire. Pareil pour un quatrième. Finalement, on finit par demander de passer une liste pour permettre un nombre arbitraire :

>>> def multiply(elements_a_multiplier):
...     res = 1
...     for i in elements_a_multiplier:
...         res = res * i
...     return res
...
>>> multiply((1, 2, 3, 4))
24

Et bien sachez qu’il existe une autre possibilité, autoriser l’ajout d’une infinité de paramètres ! Cela se fait bien sur avec « * ».

>>> def multiply(*tous_les_elements): # on ne change pas grand chose, on rajoute juste « * »
...     res = 1
...     for i in tous_les_elements):
...         res = res * i
...     return res
...
>>> multiply(1, 2, 3)
 # mais plus besoin d'une séquence !
26
>>> multiply(1, 2, 3, 4, 5)
120

Comment ça marche ? C’est simple, tout les arguments sont stockés dans une liste, et cette liste est le paramètre que l’on a désigné par « * ». Ce système très puissant peut être utilisé conjointement avec des paramètres normaux :

>>>def afficher(elem1, elem2, *elemx):
...    print(elem1)
...    print(elem2)
...    for e in elemx :
...        print("(*) %s" % e)
…
>>> afficher("Toi", "Moi", "Luke", "Anakin", "Obi Wan", "Robert")
Toi
Moi
(*) Luke
(*) Anakin
(*) Obi Wan
(*) Robert

La seule condition est de mettre « * » sur un paramètre situé après tous les autres. « * » est toujours en dernier, et il n’apparait qu’une seule fois. Enfin, il existe une convention pour le nom de cet argument : « *args ».

Bonne nouvelle, on peut utiliser aussi « ** ». Comme on peut s’y attendre, il permet de récupérer aussi une infinité de paramètres, mais sous forme de dictionnaire. Cela signifie qu’il ne récupère que les paramètres nommés :

>>> def afficher_recette(recette, **ingredients): # ingrédients sera un dictionnaire
...     print(recette)
...     for ingredient in ingredients.iteritems():
...                     print " - %s : %s" % ingredient
...
>>> afficher_recette("moukraines à la glaviouse",
...                             creme="trop", # on doit donner le nom de ce paramètre
...                             moukraines= "suffisamment",
...                             glaviouse="si disponible") # mais l'ordre des paramètres importe peu
moukraines à la glaviouse
 - glaviouse : si disponible
 - creme : trop
 - moukraines : suffisamment

Il faut également mettre « ** » après tous les autres arguments. La convention pour nommer ce paramètre est « **kwargs », pour « keyword arguments ».

Enfin, on peut mélanger tout ça d’un coup :

>>> def affichage_hybride(parametre_normal,
...                                   parametre_avec_default="valeur par défaut",
...                                   *args,
...                                   **kwargs):
...     print(parametre_normal)
...     print(parametre_avec_default)
...     print(args)
...     print(kwargs)
...
>>> affichage_hybride("param1", "param2", "infini1", "infini2", kwinfini1=1, kwinfini2=2)
param1
param2
('infini1', 'infini2')
{'kwinfini1': 1, 'kwinfini2': 2}

On doit absolument mettre les paramètres dans cet ordre :

1. paramètres normaux et obligatoires;
2. paramètres normaux facultatifs (valeur par défaut);
3. paramètres dynamiques;
4. paramètres dynamiques nommés.

En plus, cela permet en effet de faire jouer les valeurs par défaut de manière très souple :

>>> affichage_hybride("param tout seul")
param tout seul
valeur par défaut
()
{}

Si vous vous sentez à l’aise avec tout ça, vous pouvez mélanger plusieurs usages de « * » d’un coup. Je vous laisse donc en guise de conclusion un petit combo qui utilise un code précédent:

>>> def multiply(*args):
...     res = 1
...     for i in elements_a_multiplier:
...         res = res * i
...     return res
...
>>> print(multiply(*([2]*6)) == 2**6)
True

« Raw string », suggère qu’il existe un type de « chaîne brute ».

Coupons court à toute conception erronée. Il n’y a rien de tel.

Je répète.

Les « raw strings » n’existent pas.

Ce que sont les chaînes de caractères

Pour Python, dans sa petite tête de reptile automate, une chaîne est une suite de bits. Ces bits sont organisés pour former des valeurs, et chaque valeur correspond à un caractère. Cette correspondance, c’est ce qu’on appelle l’encodage. L’encodage est juste un gros tableau disant « cette valeur » vaut « ce caractère », une sorte de dictionnaire de traduction pour l’ordinateur.

Il existe beaucoup d’encodages différents, Windows utilise par exemple le CP-1552 tandis qu’Ubuntu utilise UTF-8. Si vous souhaitez faire de l’informatique de manière sérieuse, vous devez maîtriser le concept d’encodage et être capable de passer de l’un à l’autre. Comme ce n’est pas l’objectif de cet article, je vous renvoi à l’excellent article de Joel sur le sujet.

La bonne nouvelle c’est que vous pouvez comprendre la suite sans lire l’article en lien. Mais ça ne vous dispense pas de le lire plus tard.

Ce qu’il faut retenir c’est qu’une chaîne, en mémoire, est une suite de bits. Avec un encodage, il n’y a qu’une manière, et une seule, de représenter une donnée. Un saut de ligne ne se représente qu’avec une seule combinaison de bits possible. Un antislash et un ‘n’ ne se représentent qu’avec une seule suite de bits possible. Et donc « \n » et saut de ligne n’ont rien en commun en mémoire.

La donnée et sa représentation

Il y a une subtile différence entre la donnée (la valeur d’un concept) et sa représentation (comment on décrit cette valeur). Objectivement, une donnée n’existe pas, il n’y a que des représentations, mais ça ne m’aide pas beaucoup à vous expliquer alors prenons un raccourci :

• La donnée, c’est ce que stocke l’ordinateur en mémoire.
• La représentation de la donnée, c’est ce qui s’affiche.

On peut représenter la même chose de plusieurs manière. Par exemple :

• Le chiffre « 2 » peut être représenté par « 2 », « deux », ou « II ». La donnée, « le concept de 2 choses », est différent de sa représentation, c’est à dire ce qu’on écrit.
• Un dictionnaire s’écrit dans le code « dict() », ou « {} » mais vous vous imaginez bien que ce n’est pas stocké ainsi en RAM. « {} » est une représentation.
• La carte n’est pas le territoire.¹

Votre code est une représentation de ce que doit faire la machine. Ce n’est pas ce que fait la machine.

Votre ordinateur vous ment

Une représentation est toujours imparfaite, et votre ordinateur vous donne des représentations pour vous donner une idée compréhensible facilement ce qui se passe. Il simplifie volontairement les choses pour vous permettre de travailler. Vous faites de même avec lui.

Quand vous écrivez :

dico = {'name': 'guido', 'language': 'python'}

Vous dites à Python « créer un dictionnaire et lui associer le nom ‘dico’ ». C’est une convention, une manière d’écrire pour lui commander une action. Ce n’est pas l’action elle même. Un dictionnaire n’est pas stocké sous forme de « {’name’: ‘guido’, ‘language’: ‘python’} » en RAM. Cette ligne de code est la représentation d’une action, une description de ce qu’il faut faire, mais ça reste du texte.

Si vous faites un « print » sur ‘dico’, l’interpréteur va vous afficher :

{'name': 'guido', 'language': 'python'}

L’interpréteur vous affiche une représentation d’un dictionnaire lisible pour vous, humain. Ce n’est pas ce qui est stocké en mémoire, mais ça vous donne une bonne idée de ce qui s’y trouve.

Ce que fait le drapeau « r », ou pourquoi on parle de « raw string »

Il n’est pas facile de taper certains caractères, tels que les sauts de ligne. Python inclut donc un mécanisme pour les écrire facilement. Ce mécanisme est automatique, et ‘r’ permet juste de le désactiver.

Vous ne créez pas de chaîne. Au mieux vous donnez à Python une instruction pour qu’il le fasse pour vous. Cette instruction est une réprésentation. Quand vous faites :

s = 'Super chaîne avec un saut de ligne\n'

A aucun moment « Super chaîne avec un saut de ligne\n » n’est la chaîne en mémoire, c’est une représentation, une instruction donnée à Python pour créer une chaîne, tout comme “{}” n’est pas le dictionnaire en mémoire.

Vous dites à Python « créer un objet ’string’ qui contient les codes des lettres ‘Super chaîne avec un saut de ligne’ et le code d’un saut de ligne dans l’encodage courant.

Python ne garde pas les lettres en mémoire, mais des bits. Python ne garde pas « \n » en mémoire, mais le code pour « LF » ou « CR ».

« \n » ici est une représentation, une manière de dire à Python de créer une saut de ligne.

Si vous utilisez le drapeau (flag) « r » :

s = r'Super chaîne avec un saut de ligne\n'

Ici « Super chaîne avec un saut de ligne\n » n’est pas non plus la chaîne stockée en mémoire. Tout votre code est une représentation, jamais une donnée.

Vous dites à Python « créer un objet ’string’ qui contient les codes des lettres ‘Super chaîne avec un saut de ligne’ et le code de ‘\’ et le code de ‘n’.

Vous lui demander de ne pas interpréter ‘\n’ comme la représentation d’un saut de ligne, mais comme les caractères séparément. ‘r’ dit à Python de ne pas activer la fonction qui vous permet de taper facilement des sauts de lignes et autres caractères spéciaux. Vous lui demander de ne pas interpréter l’instruction, mais de la traduire directement. Vous lui demandez de faire une traduction « brute » de la « chaîne », d’où le « raw string ».

L’interpréteur, le plus gros menteur

Il n’est pas facile d’afficher un saut de ligne dans l’interpréteur. Il a donc tendance à vous donner du « \n » pour vous indiquez où ils se trouvent :

>>> s = "Test\n" # « \n » représente un saut de ligne, "line break" est stocké en mémoire

Si on affiche, Python vous ressort « \n » !

>>> print(s)
'Test\n'

Python vous indique qu’il y a un saut de ligne à la fin de « Test ». Il n’a pas stocké en mémoire « \n », il essaye juste de vous aider visuellement.
Pareil pour les caractères spéciaux :

>>> s = raw_string("Saisie : ") # saisissons un anti-slash
Saisie : \
>>> print(s)
'\\'

Comme Python utilise les « \n » pour vous indiquer où sont les caractères spéciaux, il utilise aussi antislash pour vous indiquez où ils ne sont pas !

A aucun moment Python stocke « \\ », il ne garde en mémoire que les bits pour un seul « \ » mais le représente ‘\\’ pour éviter les ambigüités.

Moralité

Quand votre programme reçoit une chaîne en entrée, elle est déjà initialisée : qu’elle vienne du Web, de la ligne de commande ou d’un formulaire de fenêtre, c’est déjà une suite de bits qui correspond à un encodage. La chaîne ne change pas (c’est un immutable), n’est pas interprétée par Python, et un « \n » reste un « \n ».

Si dans le code, vous entrez des caractères spéciaux, ce sont des instructions qui disent à Python commenter créer la chaîne en mémoire. « r » dit à Python de ne pas interpréter ces notations spéciales.

Enfin, pour éviter la confusion, Python affiche les caractères spéciaux en utilisant la même représentation que vous utilisez dans le code. De manière amusante, c’est la partie qui amène justement le plus de confusion.

Seulement comment savoir pour qui optimiser l’ergonomie ?

La réponse est simple : pour ceux qui payent.

J’entends par là que dans votre (supposée) masse d’utilisateurs, seul un petit nombre va au-delà des fonctionalités gratuites.

Ce petit nombre est celui qui a vraiment besoin de votre produit, c’est lui pour qui ses qualités ont de la valeur, le distingue de la concurrence et sont uniques. Si vous visez une niche, vous l’avez trouvé.

Considérations marketting évidentes mises à part, celà signifie que votre travail doit se concentrer sur les besoins de ces personnes, car ce sont elles qui seront fidèles et qui vont utiliser le plus le fruit de votre travail.

La bonne nouvelle donc, c’est qu’il suffit de commencer à faire payer quelque chose pour savoir vers quoi orienter vos efforts. La mauvaise, c’est qu’aussi bon ergonome que vous soyez, quels que soit les tests que vous ferez, votre design prendra toute sa valeur après rectifications suivant le retour de mise en production. Ne croyez pas pour autant que c’est une raison pour mettre en ligne un gruyère sous prétexte qu’on le corrigera plus tard. Mais en revanche, cela calme franchement les ardeurs des optimisateurs précoces.

Le deuxième effet kisscool c’est que vous allez vous apercevoir que les demandes de fonctionalité / correction de bug / [insérer ici une cause de nuit blanche] sont beaucoup plus faciles à prioriser. D’ailleurs souvent ce sont des utilisateus occasionels qui font les réclamations les plus coûteuses, et vous saurez maintenant qu’elles peuvent passer tout en bas de la pile. En revanche, en quelques heures, vous redonnerez parfois le sourire à un utilisateur assidu, et c’est la partie franchement sympa du boulot.

Maintenant votre mission, si vous l’acceptez, c’est de faire comprendre à votre client qu’il est dans son intérêt de vous rappeler 3-6 mois après le lancement pour passer une deuxième couche.

…

Et si notre produit n’a pas de fonctionalités payantes ? Et oui, il y a les intranets, les services publiques, les associations de bénévoles, les killer-apps sans modèle économique de start ups voués à la faillite et tout ce merveilleux écosystème qui sent bon le Web du XXIe siècle. Dans ce cas, la rentabilité n’est pas un facteur et vous devez seulement satisfaire les utilisateurs qui consomment le plus votre service (j’espère que vous n’avez pas de problème de financement…), alors un système de tracking du temps passé sur les pages et du nombre de visites sera votre meilleur indicateur.

Il ne reste qu’à étudier les résultats pour savoir qui se cache derrière vos fans. Leur demander directement est souvent une technique des plus efficaces. Si, si.