Luca Saiu: page officielle du cours «Introduction à la programmation»

Évaluation

Matériel du cours

Exemples et code source Python

Le code que j'ai écrit sur l'ordinatur pendant les cours (exemples simples et moins simples un peu mélangés, sans beaucoup de commentaires) :

21 octobre: méthodes

La version papier des slides décrivait certains opérations sur les collections génériquement comme «fonctions», quand en fait elles sont des méthodes. Je ne vais pas expliquer en détail la programmation à objets et le rôle des méthodes, mais en pratique c'est indispensable de connaître au moins la différence syntaxique entre l'appel d'une méthode

Malheureusement on ne peut pas ignorer cette différence : en essayant d'utiliser la syntaxe de l'appel de fonction avec une méthode

21 octobre: sharing et shallow copy

J'ai introduit la différence entre le sharing (appelé "shallow copying" dans la version papier des slides) et le vrai shallow copying :

• Dans le cas du sharing on partage un objet en mémoire, par exemple par deux variables qui pointent au même objet. Effectivement les deux variables contiennent la même adresse de mémoire, c'est-à-dire le même pointeur.
• Quand l'on fait du shallow copying sur une collection on obtient une nouvelle collection (ailleurs en mémoire), dont les éléments sont des pointeurs identiques à ceux de la structure originale : la structure n'est pas la même, mais les élements sont les mêmes.
• L'autre cas, bien clair sur la version papier aussi, et le deep copying d'une collection : la collection est dupliquée, et ses éléments sont également copiés : il n'y a aucun sharing entre la structure copiée et la structure originale, ni entre les éléments de la structure originale et les éléments de la structure copiée: les objets référés par la structure originale, même indirectement, sont tous reproduits dans un deep copy.

La différence entre sharing et shallow copying est importante en pratique si l'on travaille avec des structures complexes. C'est conceptuellement important, et utile pour raisonner sur le comportement exact des programmes et sur l'efficacité des opérations.

21 octobre: destructivité

On appelle «opérations destructives» les opérations sur une collection qui modifient la structure originale, au lieu d'en créer une autre à nouveau.

Par exemple la concaténation de listes avec l'opérateur + n'est pas destructive :

>>> a = [1, 2, 3]
>>> b = [4, 5, 6]
>>> a + b
[1, 2, 3, 4, 5, 6]

L'opérateur + a construit une nouvelle liste. Le résultat partage les éléments des deux listes données, mais les deux listes n'ont pas été modifiées :

>>> a
[1, 2, 3]
>>> b
[4, 5, 6]

Par contre, la majorité des opérations sur les collections en Python sont destructives :

>>> a.append (57)

La méthode append n'a renvoyé aucun résultat ; on peut donc imaginer que la liste originale ait été modifiée. C'est en fait le cas :

>>> a
[1, 2, 3, 57]

En fait on a perdu la version originale de la liste qui avait trois éléments. La liste existe encore, mais elle est maintenant différente.

Terminologie: certains auteurs appellent les opérations destructives «in-place», et les opérations non destructives «not-in-place» ou «out-of-place».

15 octobre: en Python les valeurs sont typées (dynamiquement); les variables ne sont pas typées du tout

La fonction type, comme toute fonction en Python, travaille sur les valeurs qu'elle reçoit en tant que paramètres et pas sur les variables liées à ces valeurs, qui peut-être n'existent même pas ; par exemple type(2 + 5) est une expression parfaitement correcte et raisonnable, et son paramètre n'est pas une variable : c'est l'expression 2 + 5, qui n'est pas (ni contient) une variable.

Dans notre pseudo-code on a des variables typées, comme dans certains vrais langages de programmation dits langages typés statiquement (par exemple : C, C++, Java, Pascal, Fortran, Ada, ML, Haskell) ; Python, par contre, est un langage typé dynamiquement (autres exemples : Lisp, Prolog, PHP, Ruby, Smalltalk). Dans un langage typé dynamiquement les variables n'ont pas de type associé : juste les valeurs ont un type.

C'est utile de raisonner sur des variables typées dans notre tête et quand l'on écrit du pseudo-code, particulièrement pour des débutants : mais si l'on utilise Python le typage des variables est juste un modèle mentale, que Python n'oblige pas de respecter.

Certains experts préfèrent les langages typés dynamiquement, certains autres les langages typés statiquement. Presque sûrement il n'existe pas de solution meilleure en tout cas : chacun des deux modèles a des mérites. Des solutions intermédiaires sont aussi possibles. (Le typage dynamique est souvent un avantage pour les experts, mais peut être un obstacle pour les débutants.)

Précisions, corrections et intégrations mineures ou avancées

Je note ici certains points plus avancés, qui sont hors sujet dans notre cours introductif. Les étudiants ne sont pas tenus à retenir les informations dans cette section. Quand même, les questions sont intéressantes et quelques-uns pourraient être encouragés à approfondir.

21 octobre: expressivité et équivalence entre boucles

Je note en retard une remarque que j'ai fait oralement pendant le premier cours.

La version papier des slides parle génériquement d'«équivalence» entre boucles mais les boucles structurés présentées dans notre pseudo-code ne sont pas toutes équivalentes entre elles.

Comment j'ai montré très informellement au tableau toute boucle pour peut être systématiquement réécrite en utilisant une boucle tant que .. faire, mais le contraire est faux (un exemple : les boucles infinies). La boucle tant que .. faire et la boucle faire .. tant que sont équivalentes entre elles : on peut systématiquement réécrite l'une en utilisant l'autre (si on a les tests).

On peut prouver formellement ces différences en puissance ou expressivité, mais c'est hors sujet pour ce cours. On peut étudier ces détails dans des cours plus théoriques sur la théorie de la calculabilité.

Ici nous avons un autre bout : nous utilisons le pseudo-code pour décrire de façon claire nos algorithmes, avant d'écrire du code. Une expression compacte et explicite de l'algorithme est bien plus importante que la minimalité : on ne cherche donc pas nécessairement de minimiser les formes possibles de boucles, car l'intention du programmer peut être mieux exprimée en utilisant une boucle moins générale et donc moins «puissante» qui respecte un motif typique : par exemple c'est bien plus claire d'utiliser une boucle pour si on veut itérer sur une séquence d'indices entiers consécutifs, même si utiliser systématiquement faire .. tant que comme la seule forme de boucle serait suffisant pour exprimer tout procès de calcul.

Réponses aux questions et suggestions pratiques

Quelques suggestions techniques et réponses aux questions des étudiants.

20 octobre: input, raw_input et Python 3

Un étudiant aimerait utiliser Python 3, mais sans être empêché par les changements incompatibles qui ont été introduits après la version 2. En particulier l'étudiant souhaiterait garder l'ancien comportement des fonctions input et raw_input.

Une solution possible consiste à exécuter ce morceau de code que j'ai écrit ; le code marche avec toute version de Python — il ne fait rien sur Python 2, mais il n'échoue pas.

import sys
# Comparaison entre deux nuplets : ordre lexcographique
if sys.version_info >= (3, 0):
  default_input = input
  # Simulation de l'ancienne fonction «raw_input» de Python 2:
  def raw_input (prompt = ""):
    return default_input (prompt)
  # Simulation de l'ancienne fonction «input» de Python 2:
  def input (prompt = ""):
    return eval (default_input (prompt))

(Oui, il y a sûrement des solutions meilleures, mais ce code au moins est à la portée des étudiants.)

Il faut exécuter le code une seule fois, par exemple en le mettant tout au début du programme. Après son exécution input et raw_input auront le comportement de Python 2.