Re: On s'en bat le steak

Oui c'est ce que je disais dans mon commentaire avec "si les objets contenus sont mutable ils pourraient être modifiés de l'extérieur malgré ça"

J'avais bien compris, mais je préférais illustrer par un exemple pour que ceux qui se demandent comment éviter ces effets de bords puissent avoir une illustration du problème. Résultat cela m'a amené à regarder s'il n'y avait pas une fonction de copie profonde d'une structure en Python, et voilà : copy.deepcopy() :-)

>>> class Test:
... def __init__(self, items=()):
... from copy import deepcopy
... self.items = list(deepcopy(items))
... 
>>> l = [1, [2, 3], 4]
>>> a = Test(l)
>>> l.append(5)
>>> l[1].append(6)
>>> l
[1, [2, 3, 6], 4, 5]
>>> a.items
[1, [2, 3], 4]

La décorrélation est totale ! \o/

Et le système d'emprunt de références va tout de même garantir qu'un seul endroit du code a la responsabilité de modification à un instant T.

C'est un système de lock pour les problèmes d'accès concurrents ? Ou si plusieurs structures se partagent une référence, seule une peut la modifier jusqu'à ce qu'elle soit désallouée et une autre en prend le contrôle, et ainsi de suite ? (j'essaye de traduire les notions de propriétaire/temps de vie).

le système de typage est moins puissant qu'en Haskell/OCaml

Il y a des travaux pour améliorer encore celui d'OCaml pour pouvoir faire du polymorphisme ad-hoc et de la surcharge d'opérateur en utilisant son système de module et les foncteurs. Et on peut aussi manipuler des références (mais là c'est sans garde-fou) et faire de la programmation système en OCaml (la seule limite actuelle, c'est le GC qui ne gère pas les accès concurrents sur la major heap ce qui pose problème pour le parallélisme, cf multicore OCaml).

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.