En fait en Python c'est pareil qu'en Java ou C# :)
Les types immutables en Python sont grosso modo là pour cacher ce que les types primitifs cachent en Java ou les types valeurs en C#. (c'est un racourci mais ca suffit pour ce qui nous intéresse).
Dans la sémantique exprimée par le langage Python, cela donne effectivement l'impression qu'il y a création d'un nouvel objet à chaque manipulation. En réalité l'interpréteur fait la même chose qu'en C# ou Java, à savoir des opérations sur des valeurs. L'objet est justement immutable pour cacher cette optimisation.
Si un entier était modifiable, il devrait être référencé en permanence par un "pointeur" (comme les autres types qui sont manipuler à travers un pointeur/adresse en interne), ce qui nécessite un intermédiaire : il faut faire un accès à une adresse mémoire pour obtenir le pointeur puis un autre accès mémoire pour accéder à la valeur référencé par le pointeur, ce dernier accès étant plus lent car effectué dans une autre partie de la mémoire. Si t'es dans une opération de type a = b + c, faut faire 3 fois ce boulot !
Je sais pas si je suis clair :)
Par contre ce que je dis là n'est pas vrai pour les types immutables qui ne sont pas "optimisés", cad qui ne cache pas des manipulations de valeur. Par exemple le type String.est en Java, C# ou Python un truc "immutable", il n'est pas pour autant utlisé en tant que valeur mais en tant que référence, pour la simple et bonne raison que la valeur contient beaucoup de données (plusieurs caractères) et de taille variable : les passer par valeur d'une méthode à une autre par exemple nécessiterait systématiquement une copie de l'intégralité des données, c'est moins coûteux de passer uniquement la référence (qui elle est stockée sous la forme d'une adresse).
Si ces types sont immutables, ce n'est pas cette fois pour cacher une optimisation du type manipulation de valeur à la place de manipulation de référence. C'est plus pour éviter au programmeur de faire n'importe quoi en manipulant le contenue d'une chaîne.
Du coup là par contre ca peut devenir très couteux de faire des opérations sur des chaînes de caractères, style :
string a = "rezzef"
a += "suite"
a += "suite2"
a += "ligne3"
Là effectivement il y a création systématique d'un nouvel objet pour stocker le résultat de la concaténation, ce qui est coûteux.
Des langages comme C# ou Java propose des classes qui cachent des chaînes de caractères "modifiables" quand c'est nécessaire (typiquement pour l'exemple ci dessus) :
StringBuilder sb = new StringBuilder("rezzef")
sb.Append("suite")
sb.Append("suite2")
sb.Append("ligne3")
string res = sb.ToString()
Dans cet exemple l'objet sb n'est pas immutable, et les appels successifs à la méthode Append modifie le contenue de la chaîne de caractère qui est stockée en interne (probablement dans un tableau de caractère), le dernier appelle permet de recopier le contenu dans une "string" classique.
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 2.
Les types immutables en Python sont grosso modo là pour cacher ce que les types primitifs cachent en Java ou les types valeurs en C#. (c'est un racourci mais ca suffit pour ce qui nous intéresse).
Dans la sémantique exprimée par le langage Python, cela donne effectivement l'impression qu'il y a création d'un nouvel objet à chaque manipulation. En réalité l'interpréteur fait la même chose qu'en C# ou Java, à savoir des opérations sur des valeurs. L'objet est justement immutable pour cacher cette optimisation.
Si un entier était modifiable, il devrait être référencé en permanence par un "pointeur" (comme les autres types qui sont manipuler à travers un pointeur/adresse en interne), ce qui nécessite un intermédiaire : il faut faire un accès à une adresse mémoire pour obtenir le pointeur puis un autre accès mémoire pour accéder à la valeur référencé par le pointeur, ce dernier accès étant plus lent car effectué dans une autre partie de la mémoire. Si t'es dans une opération de type a = b + c, faut faire 3 fois ce boulot !
Je sais pas si je suis clair :)
Par contre ce que je dis là n'est pas vrai pour les types immutables qui ne sont pas "optimisés", cad qui ne cache pas des manipulations de valeur. Par exemple le type String.est en Java, C# ou Python un truc "immutable", il n'est pas pour autant utlisé en tant que valeur mais en tant que référence, pour la simple et bonne raison que la valeur contient beaucoup de données (plusieurs caractères) et de taille variable : les passer par valeur d'une méthode à une autre par exemple nécessiterait systématiquement une copie de l'intégralité des données, c'est moins coûteux de passer uniquement la référence (qui elle est stockée sous la forme d'une adresse).
Si ces types sont immutables, ce n'est pas cette fois pour cacher une optimisation du type manipulation de valeur à la place de manipulation de référence. C'est plus pour éviter au programmeur de faire n'importe quoi en manipulant le contenue d'une chaîne.
Du coup là par contre ca peut devenir très couteux de faire des opérations sur des chaînes de caractères, style :
string a = "rezzef"
a += "suite"
a += "suite2"
a += "ligne3"
Là effectivement il y a création systématique d'un nouvel objet pour stocker le résultat de la concaténation, ce qui est coûteux.
Des langages comme C# ou Java propose des classes qui cachent des chaînes de caractères "modifiables" quand c'est nécessaire (typiquement pour l'exemple ci dessus) :
StringBuilder sb = new StringBuilder("rezzef")
sb.Append("suite")
sb.Append("suite2")
sb.Append("ligne3")
string res = sb.ToString()
Dans cet exemple l'objet sb n'est pas immutable, et les appels successifs à la méthode Append modifie le contenue de la chaîne de caractère qui est stockée en interne (probablement dans un tableau de caractère), le dernier appelle permet de recopier le contenu dans une "string" classique.