Apprendre Python et s'initier à la programmation

Lorsqu'un programme Python comporte une erreur de syntaxe, elle ne sera détectée que lors de l'exécution, étant donné qu'il s'agit d'un langage interprété et que l'interpréteur ne passe pas en revue tout le code source avant exécution. Il se peut donc très bien qu'un programme comportant des erreurs de syntaxe se soit toujours exécuté sans erreurs. C'est, par exemple, le cas lorsqu'on a un if-else dont le bloc else n'a jamais été exécuté, alors qu'il comporte une erreur de syntaxe. Examinons le code d'exemple suivant, qui comporte une erreur de syntaxe :

score = 12
if score > 10
    print('Vous avez réussi !')

Si on tente d'exécuter ce programme, on se retrouve face à l'erreur suivante :

  File "program.py", line 2
    if score > 10
                ^
SyntaxError: invalid syntax

On voit directement qu'il s'agit d'une erreur de syntaxe grâce à la dernière ligne qui commence par SyntaxError. L'interpréteur tente de décrire et situer l'erreur le plus précisément possible. Il indique qu'il y a un souci à la ligne 2 et plus précisément tout à la fin de l'instruction comme pointé par le caractère ^ de la troisième ligne. On se rend en fait compte qu'il manque le : après la condition du if.

Il faut aussi savoir qu'il y a deux cas particuliers d'erreurs de syntaxe pour lesquels le type d'erreur sera différent :

• l'indentation du code n'est pas correcte (IndentationError) ;
• il y a une inconsistance entre l'utilisation d'espaces et de tabulations pour l'indentation d'un même bloc (TabError).

IV-A-1-a-i. Erreur d'exécution▲

data = [1, 2, 3]

i = 0
while i <= len(data):
    print(data[i])
    i += 1

1
2
3
Traceback (most recent call last):
  File "program.py", line 5, in <module>
    print(data[i])
IndexError: list index out of range

IV-A-1-a-ii. Erreur logique▲

def perimeter(length, width):
    return length + width * 2

print(perimeter(2, 1))

Une première façon de gérer les erreurs passe par la documentation. On a déjà abordé rapidement ce sujet au chapitre 4, mais revenons maintenant plus en détail dessus. On va se concentrer uniquement sur la documentation des fonctions.

Le but de la documentation est de permettre à l'utilisateur d'une fonction de savoir comment l'appeler correctement et comment interpréter sa valeur de retour. Elle donne des conditions à respecter sur les valeurs des paramètres et explique quelles seront les différentes valeurs de retour possibles. Voici ce que ça pourrait donner pour la fonction percentage vue au début de ce chapitre :

# Renvoie le pourcentage d'une note étant donné :
# - "score" contient la note obtenue (flottant)
# - "total" est la note maximale atteignable (flottant)
#
# Si total <= 0, score < 0 ou score > total, alors renvoie None
def percentage(score, total):
    if total > 0 and (0 <= score <= total):
        return score / total * 100
    return None

Ce qu'on vient d'écrire est une documentation informelle. Il n'y a pas vraiment de règles à suivre et on peut se contenter d'un texte en langue naturelle. L'important est de n'oublier aucune information, afin que l'on puisse appeler et utiliser la fonction, et interpréter sa valeur de retour, sans ambigüité.

L'autre façon de décrire proprement une fonction consiste à établir ses spécifications comme présenté au chapitre 4. Pour rappel, les deux éléments suivants sont à définir :

• les préconditions sont les conditions qui doivent être satisfaites sur les paramètres et l'état global du programme, avant l'appel de la fonction ;
• les postconditions sont les conditions qui seront satisfaites sur la valeur de retour et sur l'état global du programme, après l'appel de la fonction, si les préconditions ont été respectées.

Une spécification est donc un contrat entre celui qui implémente une fonction et celui qui l'utilise. L'utilisateur s'engage à respecter les préconditions avant d'appeler la fonction et le programmeur lui garantit que les postconditions seront satisfaites en retour. Voici une nouvelle version de la fonction percentage, avec sa spécification :

# Calcule le pourcentage correspondant à une note.
#
# Pre:  0 <= score <= total, la note obtenue
#       total > 0, la note maximale atteignable
# Post: La valeur renvoyée contient le pourcentage
#       correspondant à la note obtenue.
def percentage(score, total):
    return score / total * 100

Étant donné qu'il y a un contrat, le programmeur ne doit plus se soucier du cas où les paramètres sont négatifs, ou de celui où total est nul. Il ne doit garantir le bon comportement de la fonction que pour les cas où les préconditions sont respectées, ce qui simplifie la fonction.

IV-A-1-b-i. Génération de la documentation▲

Comme on l'a déjà vu au chapitre 4, il est de bon usage, en Python, d'insérer la documentation d'une fonction sous forme d'un Docstring. Il s'agit simplement de placer une chaine de caractères, souvent délimitée par des guillemets triples pour pouvoir l'écrire sur plusieurs lignes, comme première instruction du corps de la fonction. L'exemple précédent se réécrit donc comme suit :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.

def percentage(score, total):
    """# Calcule le pourcentage correspondant à une note.
    #
    # Pre:  0 <= score <= total, la note obtenue
    #       total > 0, la note maximale atteignable
    # Post: La valeur renvoyée contient le pourcentage
    #       correspondant à la note obtenue.
    """
    return score / total * 100

Si on génère la documentation de cette fonction, à l'aide de l'outil pydoc, on obtient le résultat présenté à la figure 1, qui reprend la documentation de toutes les fonctions présentes dans un module. L'outil pydoc permet également d'exporter cette documentation en HTML.

Ce mode de programmation, qui exploite les assertions pour vérifier les préconditions, est appelé programmation défensive. Dans ce type de programmation, on suppose que les fonctions sont appelées comme il faut, dans le respect de leurs préconditions. On prévoit néanmoins un garde-fou avec des instructions assert pour vérifier que les préconditions sont effectivement bien satisfaites.

En pratique, on va utiliser ce type de programmation pour du code sur lequel on a le contrôle. Par exemple, lorsqu'on écrit un module, on peut programmer défensivement pour les fonctions qui ne sont destinées qu'à être appelées au sein de ce dernier. Lorsqu'on écrit des fonctions destinées à être utilisées par d'autres personnes, on va plutôt faire une gestion active des erreurs, notamment avec l'instruction if-else et en prévoyant des valeurs de retour spéciales.

Dans les deux cas, on doit spécifier les fonctions que l'on définit. En programmation défensive, on peut se permettre d'avoir des préconditions et faire l'hypothèse qu'elles seront toujours respectées. Par contre, lorsque les fonctions sont destinées à être utilisées par d'autres, on va limiter au maximum le nombre de préconditions.

Reprenons l'exemple du test de la sous-chaine présenté au chapitre 6. On va le réécrire sans utiliser le slicing ni l'égalité de listes, mais en faisant tout avec des opérations de base. Voici le code de la fonction issubsequence, avec sa documentation :

def issubsequence(subseq, seq):
    """Teste si une séquence est une sous-séquence d'une autre.
    
    Pre : -
    Post: La valeur renvoyée contient True si 'subseq' est une
          sous-séquence de 'seq' et False sinon.
    """
    # Vérification des paramètres
    if type(subseq) != str or type(seq) != str:
        return False
    if len(subseq) > len(seq):
        return False
    # Teste la sous-séquence à toutes les positions possibles
    for i in range(0, len(seq) - len(subseq) + 1):
        if _issubsequenceat(subseq, seq, i):
            return True
    return False

On peut faire plusieurs observations sur la définition de cette fonction qui est, pour rappel, destinée à être appelée par d'autres programmeurs :

• on a limité drastiquement le nombre de préconditions, les ramenant même au nombre de zéro ;
• on a pratiqué la gestion active des erreurs, en vérifiant que les paramètres reçus par la fonction sont corrects, et en renvoyant False le cas échéant ;
• on a fait appel à une fonction _issubsequenceat au sein de la boucle, qui permet de tester si subseq est une sous-chaine de seq en commençant à son indice i.

Voyons maintenant le code de cette dernière fonction appelée par issubsequence. Comme elle n'est pas destinée à être utilisée en dehors du module, mais uniquement par les autres fonctions du même module, on va pouvoir pratiquer la programmation défensive :

def _issubsequenceat(subseq, seq, pos):
    """Teste si une séquence est une sous-séquence d'une autre
    en commençant à un indice donné.
    
    Pre : len(subseq) <= len(seq)
          0 <= pos <= len(seq) - len(subseq)
    Post: La valeur renvoyée contient True si 'subseq' est une
          sous-séquence de 'seq' commençant à l'indice 'pos'
          et False sinon.
    """
    # Vérification des préconditions
    assert type(subseq) == str and type(seq) == str
    assert type(pos) == int
    assert len(subseq) <= len(seq)
    assert 0 <= pos <= len(seq) - len(subseq)
    # Teste la sous-séquence à la position 'pos'
    for i in range(len(subseq)):
        if seq[pos + i] != subseq[i]:
            return False
    return True

On peut faire plusieurs observations sur la définition de cette fonction qui est, pour rappel, destinée à n'être appelée que depuis les autres fonctions du même module, en l'occurrence par issubsequence :

• on a ajouté _ au début du nom de la fonction, suivant la convention Python, signalant ainsi qu'elle est privée au module ;
• on n'a pas hésité à définir plusieurs préconditions qui décrivent les paramètres valides ;
• on a pratiqué la programmation défensive, en vérifiant les préconditions à l'aide d'assertions.

Comme on l'a vu en début de chapitre, différents types d'erreurs peuvent survenir. Lorsqu'on utilise l'instruction try-except, le bloc except capture toutes les erreurs possibles qui peuvent survenir dans le bloc try correspondant. Une exception est en fait représentée par un objet, instance de la classe Exception. On peut récupérer cet objet en précisant un nom de variable après except comme dans cet exemple :

try:
    a = int(input('a ? '))
    b = int(input('b ? '))
    print(a, '/', b, '=', a / b)
except Exception as e:
    print(type(e))
    print(e)

On récupère donc l'objet de type Exception dans la variable e. Dans le bloc except, on affiche son type et sa valeur. Voici deux exemples d'exécution qui révèlent deux types d'erreurs différents :

• si on ne fournit pas un nombre entier, il ne pourra être converti en int et une erreur de type ValueError se produit :

   

  Sélectionnez

  a ? trois
  <class 'ValueError'>
  invalid literal for int() with base 10: 'trois'

• si on fournit une valeur de kitxmlcodeinlinelatexdvp0finkitxmlcodeinlinelatexdvp pour b, on aura une division par zéro qui produit une erreur de type ZeroDivisionError :

a ? 5
b ? 0
<class 'ZeroDivisionError'>
division by zero

Chaque type d'erreur est donc défini par une classe spécifique. On va pouvoir associer plusieurs blocs except à un même bloc try, pour exécuter un code différent en fonction de l'erreur capturée. Lorsqu'une erreur se produit, les blocs except sont parcourus l'un après l'autre, du premier au dernier, jusqu'à en trouver un qui corresponde à l'erreur capturée. Réécrivons l'exemple précédent en capturant les exceptions spécifiques pour les deux cas d'erreur qu'on a pu observer (erreur de conversion et division par zéro) :

try:
    a = int(input('a ? '))
    b = int(input('b ? '))
    print(a, '/', b, '=', a / b)
except ValueError:
    print('Erreur de conversion.')
except ZeroDivisionError:
    print('Division par zéro.')
except:
    print('Autre erreur.')

Remarquez tout d'abord qu'on n'est pas obligé de spécifier une variable lorsqu'on capture une exception spécifique. Cette fois-ci, lorsqu'une erreur se produit dans le bloc try, ce sera l'un des blocs except seulement qui sera exécuté, selon le type de l'erreur qui s'est produite. Le dernier bloc except est là pour prendre toutes les autres erreurs.

L'ordre des blocs except est très important et il faut les classer du plus spécifique au plus général, celui par défaut devant venir en dernier. En effet, si on commence par un bloc except pour une exception de type Exception, il sera toujours exécuté et tous les autres qui le suivent ne le seront jamais. Dans l'exemple suivant, ce sera donc toujours « Autre erreur. » qui sera affiché dès qu'une erreur se produit dans le bloc try :

try:
    a = int(input('a ? '))
    b = int(input('b ? '))
    print(a, '/', b, '=', a / b)
except Exception:
    print('Autre erreur.')
except ValueError:
    print('Erreur de conversion.')
except ZeroDivisionError:
    print('Division par zéro.')

On aura, par exemple, le résultat suivant si on spécifie une valeur nulle pour le dénominateur :

a ? 2
b ? 0
Autre erreur.

Sans s'attarder sur la raison précise de ce comportement, qui nécessiterait des notions avancées en programmation orientée objet, il faut savoir que le type Exception englobe les types ValueError et ZeroDivisionError.

IV-C-1-b-i. Gestionnaire d'erreur partagé▲

try:
    a = int(input('a ? '))
    b = int(input('b ? '))
    print(a, '/', b, '=', a / b)
except (ValueError, ZeroDivisionError) as e:
    print('Erreur de calcul :', e)
except:
    print('Autre erreur.')

a ? 2
b ? 0
Erreur de calcul : division by zero

Que se passe-t-il lorsqu'on ne capture pas une exception à l'aide d'une instruction try-except ? Cette dernière va en fait remonter la séquence des appels de fonctions. Prenons, par exemple, le programme suivant qui comporte deux fonctions, appelées en chaine :

def fun():
    print(1 / 0)

def compute():
    fun()

compute()

Le programme appelle donc la fonction compute qui, elle-même, appelle la fonction fun, cette dernière produisant une erreur à cause de la division par zéro. Voici le résultat que l'on obtient en exécutant ce programme :

Traceback (most recent call last):
  File "program.py", line 7, in <module>
    compute()
  File "program.py", line 5, in compute
    fun()
  File "program.py", line 2, in fun
    print(1 / 0)
ZeroDivisionError: division by zero

Dans un sens, la trace d'erreur permet de suivre le déroulement de l'exécution, partant du programme principal vers la fonction fun, en passant par la fonction compute. Dans l'autre sens, on peut suivre la propagation de l'erreur depuis la fonction fun vers le programme principal, en passant par la fonction compute.

Une erreur qui n'est pas capturée va donc se propager, en remontant la séquence des appels de fonctions qui ont été faits. On peut modifier le programme en capturant, par exemple, l'erreur dans la fonction compute :

def fun():
    print(1 / 0)

def compute():
    try:
        fun()
    except:
        print('Erreur.')

compute()

Dans ce cas, l'erreur qui est générée dans la fonction fun va juste se propager dans la fonction compute où elle sera arrêtée par l'instruction try-except. Le résultat de l'exécution est donc :

Erreur.

Il est important de capturer l'erreur à l'endroit où son traitement est le plus approprié, mais on ne va pas entrer dans les détails dans le cadre de ce livre consacré aux bases.

Parfois, on souhaite exécuter des instructions dans tous les cas, avant que l'exécution de continue après le bloc try-except. Le problème est que lorsqu'une erreur se produit dans le bloc try, l'exécution de ce dernier est interrompue pour se poursuivre dans le bloc except correspondant.

Pour cela, on peut utiliser le mot réservé finally qui permet d'introduire un bloc qui sera exécuté soit après que le bloc trys'est exécuté complètement sans erreur, soit après avoir exécuté le bloc except correspondant à l'erreur qui s'est produite lors de l'exécution du bloc try. On obtient ainsi une instruction try-except-finally dont voici un exemple d'utilisation :

print('Début du calcul.')
try:
    a = int(input('a ? '))
    b = int(input('b ? '))
    print('Résultat :', a / b)
except:
    print('Erreur.')
finally:
    print('Nettoyage de la mémoire.')
print('Fin du calcul.')

Si l'utilisateur fournit des valeurs correctes pour a et b, l'exécution du bloc try se passera sans erreur, c'est-à-dire que le résultat de la division de a par b sera affiché, puis que la phrase signalant que la mémoire est nettoyée sera affichée :

Début du calcul.
a ? 2
b ? 8
Résultat : 0.25
Nettoyage de la mémoire.
Fin du calcul.

Le bloc finally a donc bien été exécuté, après l'exécution sans erreur du bloc try et avant que l'exécution du programme ne continue après l'instruction try-except.

Par contre, si une erreur se produit, alors le résultat ne sera pas affiché puisque le bloc try sera arrêté ; on aura simplement l'affichage d'un message d'erreur. Par contre, la phrase signalant que la mémoire est nettoyée sera de nouveau affichée témoignant bien du fait que le bloc finally a été exécuté, cette fois-ci après le bloc except, mais toujours avant la reprise de l'exécution après l'instruction try-except :

Début du calcul.
a ? 2
b ? 0
Erreur.
Nettoyage de la mémoire.
Fin du calcul.

Enfin, sachez que l'on peut se limiter à une instruction try-finally, sans définir un seul bloc except. Dans ce cas, si une erreur se produit dans le bloc try, elle sera propagée après exécution du bloc finally.

Dans l'exemple précédent, on a généré une exception de type ArithmeticError, dont la classe existe déjà en Python. On pourrait se limiter aux types d'exceptions déjà existants, voire utiliser le type générique Exception, mais il est parfois plus pratique et plus lisible de définir ses propres types. Pour cela, il suffit de définir une nouvelle classe, comme le montre l'exemple suivant :

class NoRootException(Exception):
    pass

Cette classe est tout simplement vide puisque son corps n'est constitué que de l'instruction pass qui, pour rappel, ne fait juste rien.

On remarque néanmoins une petite différence par rapport à ce qu'on a vu sur la définition de classe, c'est le Exception qui a été ajouté entre parenthèses après le nom de la classe. Sans rentrer dans le détail, cela permet de signifier à Python que cette classe est de « type exception », ce qui permettra de l'utiliser avec try-except et raise.

Une fois cette classe définie, on va pouvoir l'utiliser. Définissons une fonction trinomialroots qui calcule et renvoie les racines d'un trinôme du second degré de la forme kitxmlcodeinlinelatexdvpax^2 + bx + cfinkitxmlcodeinlinelatexdvp, mais qui, contrairement à la version vue au chapitre 3, génère une erreur lorsqu'il n'y a pas de racine réelle :

from math import sqrt

def trinomialroots(a, b, c):
    delta = b ** 2 - 4 * a * c
    # Aucune racine réelle
    if delta < 0:
        raise NoRootException()
    # Une racine réelle double
    if delta == 0:
        return -b / (2 * a)
    # Deux racines réelles simples
    x1 = (-b + sqrt(delta)) / (2 * a)
    x2 = (-b - sqrt(delta)) / (2 * a)
    return (x1, x2)

La quatrième ligne du corps de la fonction génère une erreur de type NoRootException à l'aide de l'instruction raise, dans le cas où le trinôme n'admet pas de racine réelle. Pour que ce programme fonctionne, il faut évidemment que la classe NoRootException soit définie dans le même fichier que la fonction trinomialroots.

Lorsqu'on appelle cette fonction, on va donc pouvoir utiliser l'instruction try-except pour attraper cette erreur, lorsqu'elle survient. Essayons, par exemple, de calculer et d'afficher les racines réelles du trinôme kitxmlcodeinlinelatexdvpx^2 + 2finkitxmlcodeinlinelatexdvp. Pour cela, on appelle donc la fonction trinomialroots en lui passant en paramètres kitxmlcodeinlinelatexdvp1finkitxmlcodeinlinelatexdvp, kitxmlcodeinlinelatexdvp0finkitxmlcodeinlinelatexdvp et kitxmlcodeinlinelatexdvp2finkitxmlcodeinlinelatexdvp puisque kitxmlcodeinlinelatexdvpx^2 + 2finkitxmlcodeinlinelatexdvp correspond à kitxmlcodeinlinelatexdvpa = 1finkitxmlcodeinlinelatexdvp, kitxmlcodeinlinelatexdvpb = 0finkitxmlcodeinlinelatexdvp et kitxmlcodeinlinelatexdvpc = 2finkitxmlcodeinlinelatexdvp :

try:
    print(trinomialroots(1, 0, 2))
except NoRootException:
    print('Pas de racine réelle.')

Puisque ce trinôme n'admet pas de racine réelle, la parabole correspondante se trouvant au-dessus de l'axe des kitxmlcodeinlinelatexdvpxfinkitxmlcodeinlinelatexdvp, une erreur sera générée et capturée par le bloc except, comme on le constate sur le résultat de l'exécution du programme :

Pas de racine réelle.

Tout ceci est donc possible, car on a défini une nouvelle classe de « type exception », permettant de générer une erreur de ce type avec raise et de l'attraper avec except.

Une exception se définit par une classe, et on peut donc y ajouter tout ce qu'on a vu, à savoir des variables d'instance, des accesseurs, des mutateurs et des méthodes. Cette possibilité permet de paramétrer l'exception, c'est-à-dire de lui ajouter de l'information. En récupérant l'objet correspondant à l'exception dans l'instruction except, on pourra l'utiliser et donc, par exemple, appeler ses méthodes.

Si on revient sur l'exemple des racines du trinôme du second degré, il pourrait être utile de connaitre la valeur du discriminant lorsqu'aucune racine réelle n'existe. On va pour cela ajouter une variable d'instance et un accesseur à la classe NoRootException :

class NoRootException(Exception):
    def __init__(self, delta):
        self.__delta = delta

    @property
    def delta(self):
        return self.__delta

On modifie ensuite l'instruction qui génère l'erreur dans la fonction trinomialroots, puisqu'il faut maintenant passer un paramètre lors de la création d'un nouvel objet de type NoRootException :

raise NoRootException(delta)

On peut maintenant récupérer la valeur du discriminant dans le bloc except, à partir de l'objet représentant l'exception qui s'est produite. Il suffit pour cela de faire appel à l'accesseur delta :

try:
    print(trinomialroots(1, 0, 2))
except NoRootException as e:
    print('Pas de racine réelle.')
    print('Delta =', e.delta)

L'exécution de ce programme affiche donc la valeur dudit discriminant, et on voit bien qu'il est négatif :

Pas de racine réelle.
Delta = -8