Je voudrais utiliser des pointeurs ou, tout au moins, pouvoir simuler la notion de référence: c'est possible ? si oui, comment ?
Toutes les variables sont des références. Que veux-tu faire précisemment ?
Bruno
NicoEFE
Bruno Desthuilliers wrote in message news:<41a475df$0$3050$...
Nogfx wrote:
Je voudrais utiliser des pointeurs ou, tout au moins, pouvoir simuler la notion de référence: c'est possible ? si oui, comment ?
Toutes les variables sont des références. Que veux-tu faire précisemment ?
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z qui font reference à cette variable x: une modification de y.champs1 entraine la modification de x.champs1 (forcément, y "pointait" vers x) et ce changement se trouve repercuté sur y (forcément),...
=> Je fais ca comment ?
@+, Léo.
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote in message news:<41a475df$0$3050$626a14ce@news.free.fr>...
Nogfx wrote:
Je voudrais utiliser des pointeurs ou, tout au moins, pouvoir simuler
la notion de référence: c'est possible ? si oui, comment ?
Toutes les variables sont des références.
Que veux-tu faire précisemment ?
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z
qui font reference à cette variable x: une modification de y.champs1
entraine la modification de x.champs1 (forcément, y "pointait" vers x)
et ce changement se trouve repercuté sur y (forcément),...
Bruno Desthuilliers wrote in message news:<41a475df$0$3050$...
Nogfx wrote:
Je voudrais utiliser des pointeurs ou, tout au moins, pouvoir simuler la notion de référence: c'est possible ? si oui, comment ?
Toutes les variables sont des références. Que veux-tu faire précisemment ?
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z qui font reference à cette variable x: une modification de y.champs1 entraine la modification de x.champs1 (forcément, y "pointait" vers x) et ce changement se trouve repercuté sur y (forcément),...
=> Je fais ca comment ?
@+, Léo.
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonsoir !
Amuse-toi avec ce bout de code : x=[1] y=x print x #==> [1] print y #==> [1]
x[0]9 print x #==> [999] print y #==> [999]
Bonsoir !
Amuse-toi avec ce bout de code :
x=[1]
y=x
print x #==> [1]
print y #==> [1]
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z qui font reference à cette variable x: une modification de y.champs1 entraine la modification de x.champs1 (forcément, y "pointait" vers x) et ce changement se trouve repercuté sur y (forcément),...
Salut
je ne suis pas spécialiste de Python mais en C++ je ferais ceci : mettre champs1 de x,y,z en privé faire un accesseur à champ1 : get_champ1() une méthode qui retourne simplement champ1
faire un modificateur de champ1 : set_champ1(value) une méthode qui modifie l'attribut privé champ1
Dans ton modificateur de y.champs1, tu appelles le modificateur de x.champs1
On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier.
mais comme j'ai dit plus haut... je ne suis pas spécialiste de Python... de C++ non plus... et d'ailleurs je ne suis spécialiste d'aucun langage ;-)
@+
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z
qui font reference à cette variable x: une modification de y.champs1
entraine la modification de x.champs1 (forcément, y "pointait" vers x)
et ce changement se trouve repercuté sur y (forcément),...
Salut
je ne suis pas spécialiste de Python mais en C++ je ferais ceci :
mettre champs1 de x,y,z en privé
faire un accesseur à champ1 : get_champ1()
une méthode qui retourne simplement champ1
faire un modificateur de champ1 : set_champ1(value)
une méthode qui modifie l'attribut privé champ1
Dans ton modificateur de y.champs1, tu appelles le modificateur de
x.champs1
On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire
des accesseurs/modificateurs... cela permet de cacher la structure interne
de ton objet au cas où tu venais à la modifier.
mais comme j'ai dit plus haut... je ne suis pas spécialiste de Python...
de C++ non plus... et d'ailleurs je ne suis spécialiste d'aucun langage ;-)
Je veux pouvoir avoir une variable x et deux (ou plus) variables y,z qui font reference à cette variable x: une modification de y.champs1 entraine la modification de x.champs1 (forcément, y "pointait" vers x) et ce changement se trouve repercuté sur y (forcément),...
Salut
je ne suis pas spécialiste de Python mais en C++ je ferais ceci : mettre champs1 de x,y,z en privé faire un accesseur à champ1 : get_champ1() une méthode qui retourne simplement champ1
faire un modificateur de champ1 : set_champ1(value) une méthode qui modifie l'attribut privé champ1
Dans ton modificateur de y.champs1, tu appelles le modificateur de x.champs1
On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier.
mais comme j'ai dit plus haut... je ne suis pas spécialiste de Python... de C++ non plus... et d'ailleurs je ne suis spécialiste d'aucun langage ;-)
@+
Yermat
wrote:
[...] On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier. [...]
Exact... enfin pour des langages tel que C++ ou Java mais pour python, ce serait plutôt l'inverse. En effet, il est plus facile de transformer un attribut en accesseur que l'inverse et en plus ça rends le code plus lisible.
Voici un exemple bête :
class Test(object): ... def __init__(self, val):
... self.val = val ...
t = Test(1) t.val 1
t.val = 2 t.val 2
class Test1(object): ... def __init__(self, val):
... self._val2 = 2 * val ... def getVal(self): ... return self._val2 / 2 ... def setVal(self, val): ... self._val2 = 2 * val ... val = property(getVal, setVal) ...
t = Test1(1) t.val 1
t.val = 2 t.val 2
t._val2 4
-- Yermat
noone@nowhere.com wrote:
[...]
On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire
des accesseurs/modificateurs... cela permet de cacher la structure interne
de ton objet au cas où tu venais à la modifier.
[...]
Exact... enfin pour des langages tel que C++ ou Java mais pour python,
ce serait plutôt l'inverse. En effet, il est plus facile de transformer
un attribut en accesseur que l'inverse et en plus ça rends le code plus
lisible.
Voici un exemple bête :
class Test(object):
... def __init__(self, val):
... self.val = val
...
t = Test(1)
t.val
1
t.val = 2
t.val
2
class Test1(object):
... def __init__(self, val):
... self._val2 = 2 * val
... def getVal(self):
... return self._val2 / 2
... def setVal(self, val):
... self._val2 = 2 * val
... val = property(getVal, setVal)
...
[...] On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier. [...]
Exact... enfin pour des langages tel que C++ ou Java mais pour python, ce serait plutôt l'inverse. En effet, il est plus facile de transformer un attribut en accesseur que l'inverse et en plus ça rends le code plus lisible.
Voici un exemple bête :
class Test(object): ... def __init__(self, val):
... self.val = val ...
t = Test(1) t.val 1
t.val = 2 t.val 2
class Test1(object): ... def __init__(self, val):
... self._val2 = 2 * val ... def getVal(self): ... return self._val2 / 2 ... def setVal(self, val): ... self._val2 = 2 * val ... val = property(getVal, setVal) ...
t = Test1(1) t.val 1
t.val = 2 t.val 2
t._val2 4
-- Yermat
Yermat
Yermat wrote:
wrote:
[...] On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier. [...]
Pour appuyer encore plus ce que je disais : http://dirtsimple.org/2004/12/python-is-not-java.html
Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.
In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.
-- Yermat
Yermat wrote:
noone@nowhere.com wrote:
[...]
On m'a toujours dit de ne jamais mettre d'attribut public... mais de
faire
des accesseurs/modificateurs... cela permet de cacher la structure
interne
de ton objet au cas où tu venais à la modifier.
[...]
Pour appuyer encore plus ce que je disais :
http://dirtsimple.org/2004/12/python-is-not-java.html
Getters and setters are evil. Evil, evil, I say! Python objects are not
Java beans. Do not write getters and setters. This is what the
'property' built-in is for. And do not take that to mean that you should
write getters and setters, and then wrap them in 'property'. That means
that until you prove that you need anything more than a simple attribute
access, don't write getters and setters. They are a waste of CPU time,
but more important, they are a waste of programmer time. Not just for
the people writing the code and tests, but for the people who have to
read and understand them as well.
In Java, you have to use getters and setters because using public fields
gives you no opportunity to go back and change your mind later to using
getters and setters. So in Java, you might as well get the chore out of
the way up front. In Python, this is silly, because you can start with a
normal attribute and change your mind at any time, without affecting any
clients of the class. So, don't write getters and setters.
[...] On m'a toujours dit de ne jamais mettre d'attribut public... mais de faire des accesseurs/modificateurs... cela permet de cacher la structure interne de ton objet au cas où tu venais à la modifier. [...]
Pour appuyer encore plus ce que je disais : http://dirtsimple.org/2004/12/python-is-not-java.html
Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.
In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.
-- Yermat
Laurent Pointal
Bruno Desthuilliers wrote:
En Python, toutes les variables sont des références sur des objets. L'id d'un objet est PAQJS son adresse mémoire.
En C-Python c'est l'adresse mémoire qui est utilisée comme id. Mais il est très fortement conseillé de ne pas se reposer là-dessus...
<< id( object)
Return the `identity' of an object. This is an integer (or long integer) which is guaranteed to be unique and constant for this object during its lifetime. Two objects whose lifetimes are disjunct may have the same id() value. (Implementation note: this is the address of the object.)
A+
Laurent.
Bruno Desthuilliers wrote:
En Python, toutes les variables sont des références sur des objets. L'id
d'un objet est PAQJS son adresse mémoire.
En C-Python c'est l'adresse mémoire qui est utilisée comme id. Mais il
est très fortement conseillé de ne pas se reposer là-dessus...
<<
id( object)
Return the `identity' of an object. This is an integer (or long integer)
which is guaranteed to be unique and constant for this object during its
lifetime. Two objects whose lifetimes are disjunct may have the same
id() value. (Implementation note: this is the address of the object.)
En Python, toutes les variables sont des références sur des objets. L'id d'un objet est PAQJS son adresse mémoire.
En C-Python c'est l'adresse mémoire qui est utilisée comme id. Mais il est très fortement conseillé de ne pas se reposer là-dessus...
<< id( object)
Return the `identity' of an object. This is an integer (or long integer) which is guaranteed to be unique and constant for this object during its lifetime. Two objects whose lifetimes are disjunct may have the same id() value. (Implementation note: this is the address of the object.)
