[Python] Affectation de variables, comment les lire ? - Page 1

yop,

je lis un bouquin de Python, ça a l'air surpuissant ce langage, tout existe déjà dans la bibliothèque standard, ya plus rien à faire. Oui, quand on vient de l'asm ou du C, ça change

Bon, par contre, je découvre un truc qui me laisse pantois :>>> fable = ['Je','plie','mais','ne','romps','point'] >>> phrase = fable >>> fable[4] ='casse' >>> phrase ['Je', 'plie', 'mais', 'ne', 'casse', 'point']
J'aurais cru à un mécanisme de copy on write, comme en C++, mais il n'en est rien. Alors c'est quoi, une variable Python, faut la lire comment ? Comme une référence, comme un pointeur ? Pas comme une variable locale dont la valeur est sur la pile en tout cas.
Je sais pas trop à quoi me raccrocher, dans ce que je connais déjà, mais j'ai l'impression que ce genre de trucs est bien casse-gueule.

Pourtant, je lisais ce matin ceci : https://docs.python.org/3/reference/datamodel.html#objects-values-and-types

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to refer to two different, unique, newly created empty lists. (Note that c = d = [] assigns the same object to both c and d.)

Donc j'aurais jamais immaginé ce comportement.

Question subsidiaire, comme faire pour forcer une vraie copie ? Mon bouquin n'en parle pas encore au stade où j'en suis. ><
J'imagine que tous les objets disposent d'une méthode identique pour ça ?

Merci d'avance.

ya une fonction pour ca, voir https://docs.python.org/2/library/copy.html

Ok, donc on peut bien faire une copie profonde ou superficielle, merci. Marrant. Je sens que je vais facilement me faire baiser

Pour ton premier exemple, les variables en Python contiennent effectivement des références vers leurs valeurs. Du coup "phrase = fable" te laisse avec deux variables qui partagent la même référence, que tu fasses ta modification en passant par l'une ou par l'autre ne change rien.

Tu peux considérer que toutes les variables fonctionnent toujours comme ça, même si en pratique la VM fait probablement plein de raccourcis quand tu manipules par exemple des entiers, pour éviter de payer le prix fort à chaque opération. De ton point de vue en tout cas, ça devrait être transparent. Te connaissant tu vas avoir du mal à t'empêcher d'aller regarder sous le capot, mais ça a été conçu pour que tu n'aies pas à te poser ce genre de questions

Plus précisément, tu as 3 catégories d'objets :
* les objets uniques (comme None ou ... )
* les objets immutables (str, float, int, bool, tuples, frozenDict, …)
* les objets mutables (tout le reste)

Du coup, on prend vite l'habitude de faire les copy ou non (personnellement, en pratique, je ne me sers jamais de copy).

Ok merci, le cours que j'ai insiste bien sur ces notions de mutable ou pas, mais il ne parle pas (encore) d'objets uniques, je les ai découverts dans la doc du langage : https://docs.python.org/3/
Pénible d'ailleurs cette doc, en tout cas pour apprendre, parce que c'est une encyclopédie très formaliste et non un cours. Dans l'idée j'aime bien (vu que j'aime pas les tutos), mais trop c'est trop. Mais on fera avec.

Zeph (./4) :
De ton point de vue en tout cas, ça devrait être transparent. Te connaissant tu vas avoir du mal à t'empêcher d'aller regarder sous le capot, mais ça a été conçu pour que tu n'aies pas à te poser ce genre de questions

C'est exactement ce que j'attends d'un langage de script. J'ai déjà regardé du côté de tkinter, et de quelques classes de base, on peut déjà faire plein de trucs sans connaitre grand chose, 100% plus vite qu'avec Qt Designer ou assimilés, qui mâchent déjà beaucoup de boulot.
J'ai aucune envie de regarder sous le capot, pour une fois, je veux de l'efficace et simple

Folco (./6) :
J'ai aucune envie de regarder sous le capot, pour une fois

Ouais ouais ouais, on dit ça

Folco (./1) :
Bon, par contre, je découvre un truc qui me laisse pantois :>>> fable = ['Je','plie','mais','ne','romps','point'] >>> phrase = fable >>> fable[4] ='casse' >>> phrase ['Je', 'plie', 'mais', 'ne', 'casse', 'point']
J'aurais cru à un mécanisme de copy on write, comme en C++, mais il n'en est rien. Alors c'est quoi, une variable Python, faut la lire comment ? Comme une référence, comme un pointeur ? Pas comme une variable locale dont la valeur est sur la pile en tout cas.Je sais pas trop à quoi me raccrocher, dans ce que je connais déjà, mais j'ai l'impression que ce genre de trucs est bien casse-gueule.

Les joies du partage explicit…

Il y a le même comportement débile en de nombreux autres languages, du Java au Visual Basic. C'est une approche vraiment tordue: "Il n'y a pas de pointeurs, mais en réalité, tout est un pointeur, débrouille-toi!" Si tu as la chance, il y a une fonction genre clone (Java) ou copy (Python) qui te permet de faire manuellement le boulot du language; si c'est un langage pourri comme le VB, il n'y a même pas ça.

Le partage implicit (copy on write) de Qt est tellement plus pratique!

Pourtant, je lisais ce matin ceci : https://docs.python.org/3/reference/datamodel.html#objects-values-and-types

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to refer to two different, unique, newly created empty lists. (Note that c = d = [] assigns the same object to both c and d.)

Donc j'aurais jamais immaginé ce comportement.

Tu as zappé la petite phrase entre parenthèses à la fin: "Note that c = d = [] assigns the same object to both c and d." C'est la plus importante, mais comme elle montre un énorme défaut du langage, elle a été cachée dans une paire de parenthèses à la fin du paragraphe.

En effet, j'avais pas percuté la portée de cette phrase en la lisant, j'ai compris qu'avec l'exemple de code.

J'aime le côté toujours impartial de Kevin

Au fait, l'aliasing, ça sert à quoi ? Quel intérêt d'avoir plusieurs noms pour la même référence ?

Folco (./11) :
Au fait, l'aliasing, ça sert à quoi ? Quel intérêt d'avoir plusieurs noms pour la même référence ?

Folco (./3) :
Je sens que je vais facilement me faire baiser

GT

Folco (./11) :


Au fait, l'aliasing, ça sert à quoi ? Quel intérêt d'avoir plusieurs noms pour la même référence ?

Ça va dépendre du contexte, mais voilà un petit exemple simple :

val1 = val2 = ["résultat"]
if toto:
    val2 = ["autre résultat"]
return val1, val2

Sinon, ta variable peut être un objet de configuration qui est passé à tous les méthodes/objets de ton programme pour éviter une variable globale (ou parce qu'il y a plusieurs configs possibles simultanément)… à chaque fois qu'une variable sera réutilisée en plusieurs endroits de ton code (avec des scopes différents), tu auras de l'aliasing.

Même avec des scopes différents ? Je comprends pas. Si je passe une variable en argument (en fait, ça référence), et que cet argument est modifié par la fonction, la variable initiale ne sera pas modifiée, sauf si elle est déclarée global par la fonction, c'est pas ça ?

Sinon, je ne savais pas qu'on pouvait retourner plusieurs valeurs simultanément, c'est puissant comme type de fonction, et ça évite de passer un pointeur de structure comme en C.
Mais je sais pas encore utiliser ça.