De même, la distinction entre attribut d'instance et
attribut de classe n'est pas hyper-tranchée non plus: tu peux avoir des
attributs calculés définis au niveau de la classe qui vont renvoyer des
valeurs différentes en fonction de l'instance. Ou pas, comme dans
l'exemple ci-dessus... Donc demander à ne récupérer que les attributs
d'une instance n'a pas forcément grand sens...
... ben en fait, dans mon esprit, les choses étaient tranchées avant que
je ne lance ce post. Je voyais les choses ainsi :
un objet obj possède un espace de noms que j'appelle N, qui contient (ou
pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de variables
appartenant à N.
Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance donnée
et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
De même, la distinction entre attribut d'instance et
attribut de classe n'est pas hyper-tranchée non plus: tu peux avoir des
attributs calculés définis au niveau de la classe qui vont renvoyer des
valeurs différentes en fonction de l'instance. Ou pas, comme dans
l'exemple ci-dessus... Donc demander à ne récupérer que les attributs
d'une instance n'a pas forcément grand sens...
... ben en fait, dans mon esprit, les choses étaient tranchées avant que
je ne lance ce post. Je voyais les choses ainsi :
un objet obj possède un espace de noms que j'appelle N, qui contient (ou
pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de variables
appartenant à N.
Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance donnée
et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
De même, la distinction entre attribut d'instance et
attribut de classe n'est pas hyper-tranchée non plus: tu peux avoir des
attributs calculés définis au niveau de la classe qui vont renvoyer des
valeurs différentes en fonction de l'instance. Ou pas, comme dans
l'exemple ci-dessus... Donc demander à ne récupérer que les attributs
d'une instance n'a pas forcément grand sens...
... ben en fait, dans mon esprit, les choses étaient tranchées avant que
je ne lance ce post. Je voyais les choses ainsi :
un objet obj possède un espace de noms que j'appelle N, qui contient (ou
pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de variables
appartenant à N.
Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance donnée
et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
un objet obj possède un espace de noms que j'appelle N, qui contient
(ou pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de
variables appartenant à N.
Si c'est ça que tu veux, ton espace de nom N est strictement
obj.__dict__. Mais comme tu as pu le constater, ça ne va pas t'amener
très loin...Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance
donnée et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
Concevoir, je ne sais pas... Mais le fait est qu'en Python, un objet o
donne accès à plein de choses qui ne sont pas dans o.__dict__. Donc se
limiter aux attributs présents dans o.__dict__ paraît a priori très
limitatif.
un objet obj possède un espace de noms que j'appelle N, qui contient
(ou pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de
variables appartenant à N.
Si c'est ça que tu veux, ton espace de nom N est strictement
obj.__dict__. Mais comme tu as pu le constater, ça ne va pas t'amener
très loin...
Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance
donnée et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
Concevoir, je ne sais pas... Mais le fait est qu'en Python, un objet o
donne accès à plein de choses qui ne sont pas dans o.__dict__. Donc se
limiter aux attributs présents dans o.__dict__ paraît a priori très
limitatif.
un objet obj possède un espace de noms que j'appelle N, qui contient
(ou pas) des noms de variables (on peut avoir N = vide). Pour moi, les
attributs de l'objet obj sont tous les objets liés aux noms de
variables appartenant à N.
Si c'est ça que tu veux, ton espace de nom N est strictement
obj.__dict__. Mais comme tu as pu le constater, ça ne va pas t'amener
très loin...Donc dans mon esprit, avec cette façon de voir, il y avait une
distinction très tranchée et nette entre attribut d'une instance
donnée et attribut de la classe.
Mais, ce n'est pas comme cela qu'il faut concevoir le modèle objet ?
Concevoir, je ne sais pas... Mais le fait est qu'en Python, un objet o
donne accès à plein de choses qui ne sont pas dans o.__dict__. Donc se
limiter aux attributs présents dans o.__dict__ paraît a priori très
limitatif.
Bonsoir !
Tu aurais pu choisir autre chose que "MC" pour ta classe.
À chaque fois, je crois qu'on parle de moi, dans mon dos...
Bonsoir !
Tu aurais pu choisir autre chose que "MC" pour ta classe.
À chaque fois, je crois qu'on parle de moi, dans mon dos...
Bonsoir !
Tu aurais pu choisir autre chose que "MC" pour ta classe.
À chaque fois, je crois qu'on parle de moi, dans mon dos...
Merci bien pour vos réponses respectives.
Effectivement, je comprends bien l'erreur qui consiste à dire que seuls
les objets référencés dans l'espace de nom de obj sont des attributs de
obj. En effet, une méthode n'est jamais dans l'espace de nom d'une
instance
et pourtant on parle bien de "méthodes liées à un objet
instance". Si C est une classe dans laquelle on définit une méthode m
et
si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m sont
tous les deux des objets méthodes bien distincts,
et sont bien des
méthodes liées chacune respectivement à o1 et o2, donc on peut vraiment
dire que ce sont des attributs respectivement de o1 et o2 (vu qu'ils
sont liés avec eux).
En résumé :
« m attribut de C » : pas de sens.
« C.m attribut de C » : oui c'est un objet méthode non liée
« o1.m attribut de o1 » : oui c'est un objet méthode liée à o1
Désolé pour ces trivialités. Je confondais la notion d'attribut (issu du
*modèle* objet)
avec la notion d'espace de nom qui relève plutôt de
*l'implémentation* du modèle objet en Python.
Merci bien pour votre aide.
Merci bien pour vos réponses respectives.
Effectivement, je comprends bien l'erreur qui consiste à dire que seuls
les objets référencés dans l'espace de nom de obj sont des attributs de
obj. En effet, une méthode n'est jamais dans l'espace de nom d'une
instance
et pourtant on parle bien de "méthodes liées à un objet
instance". Si C est une classe dans laquelle on définit une méthode m
et
si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m sont
tous les deux des objets méthodes bien distincts,
et sont bien des
méthodes liées chacune respectivement à o1 et o2, donc on peut vraiment
dire que ce sont des attributs respectivement de o1 et o2 (vu qu'ils
sont liés avec eux).
En résumé :
« m attribut de C » : pas de sens.
« C.m attribut de C » : oui c'est un objet méthode non liée
« o1.m attribut de o1 » : oui c'est un objet méthode liée à o1
Désolé pour ces trivialités. Je confondais la notion d'attribut (issu du
*modèle* objet)
avec la notion d'espace de nom qui relève plutôt de
*l'implémentation* du modèle objet en Python.
Merci bien pour votre aide.
Merci bien pour vos réponses respectives.
Effectivement, je comprends bien l'erreur qui consiste à dire que seuls
les objets référencés dans l'espace de nom de obj sont des attributs de
obj. En effet, une méthode n'est jamais dans l'espace de nom d'une
instance
et pourtant on parle bien de "méthodes liées à un objet
instance". Si C est une classe dans laquelle on définit une méthode m
et
si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m sont
tous les deux des objets méthodes bien distincts,
et sont bien des
méthodes liées chacune respectivement à o1 et o2, donc on peut vraiment
dire que ce sont des attributs respectivement de o1 et o2 (vu qu'ils
sont liés avec eux).
En résumé :
« m attribut de C » : pas de sens.
« C.m attribut de C » : oui c'est un objet méthode non liée
« o1.m attribut de o1 » : oui c'est un objet méthode liée à o1
Désolé pour ces trivialités. Je confondais la notion d'attribut (issu du
*modèle* objet)
avec la notion d'espace de nom qui relève plutôt de
*l'implémentation* du modèle objet en Python.
Merci bien pour votre aide.
Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
et pourtant on parle bien de "méthodes liées à un objet instance". Si
C est une classe dans laquelle on définit une méthode m
<pedant>
A vrai dire, ce qui est défini dans C est une fonction. C'est lors de la
résolution d'attribut que la méthode est instanciée.
</pedant>
et si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m
sont tous les deux des objets méthodes bien distincts,
Ce qui ne prouve rien, puisque tu a le même comportement avec deux
lookups successif de o1.m :
m1 = o1.m
m2 = o1.m
m1 is m2
=> False
En résumé :
« m attribut de C » : pas de sens.
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire, ne
lève pas un AttributeError.
Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
et pourtant on parle bien de "méthodes liées à un objet instance". Si
C est une classe dans laquelle on définit une méthode m
<pedant>
A vrai dire, ce qui est défini dans C est une fonction. C'est lors de la
résolution d'attribut que la méthode est instanciée.
</pedant>
et si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m
sont tous les deux des objets méthodes bien distincts,
Ce qui ne prouve rien, puisque tu a le même comportement avec deux
lookups successif de o1.m :
m1 = o1.m
m2 = o1.m
m1 is m2
=> False
En résumé :
« m attribut de C » : pas de sens.
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire, ne
lève pas un AttributeError.
Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
et pourtant on parle bien de "méthodes liées à un objet instance". Si
C est une classe dans laquelle on définit une méthode m
<pedant>
A vrai dire, ce qui est défini dans C est une fonction. C'est lors de la
résolution d'attribut que la méthode est instanciée.
</pedant>
et si o1 et o2 sont deux instances de C, alors les objets o1.m et o2.m
sont tous les deux des objets méthodes bien distincts,
Ce qui ne prouve rien, puisque tu a le même comportement avec deux
lookups successif de o1.m :
m1 = o1.m
m2 = o1.m
m1 is m2
=> False
En résumé :
« m attribut de C » : pas de sens.
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire, ne
lève pas un AttributeError.
Merci bien pour ta réponse Bruno.
Bruno Desthuilliers a écrit :Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
Certes, mais c'est de la triche. :-)
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
m (je
veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des objets
bien différents, si m est une méthode par exemple) ?
C'est à cause de
cette question que je trouvais que la phrase « m est un attribut de C »
n'avait pas de sens ; parce que je ne sais pas de quel objet Python du
programme on parle quand on dit "m".
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire,
ne lève pas un AttributeError.
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
Est-ce un objet référencé par
l'identificateur A se trouvant dans un espace de nom particulier
Merci bien pour ta réponse Bruno.
Bruno Desthuilliers a écrit :
Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
Certes, mais c'est de la triche. :-)
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
m (je
veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des objets
bien différents, si m est une méthode par exemple) ?
C'est à cause de
cette question que je trouvais que la phrase « m est un attribut de C »
n'avait pas de sens ; parce que je ne sais pas de quel objet Python du
programme on parle quand on dit "m".
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire,
ne lève pas un AttributeError.
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
Est-ce un objet référencé par
l'identificateur A se trouvant dans un espace de nom particulier
Merci bien pour ta réponse Bruno.
Bruno Desthuilliers a écrit :Effectivement, je comprends bien l'erreur qui consiste à dire que
seuls les objets référencés dans l'espace de nom de obj sont des
attributs de obj. En effet, une méthode n'est jamais dans l'espace de
nom d'une instance
"jamais" ?-)
def foo(obj):
print obj
class Bar(object):
def __init__(self):
self.foo = foo.__get__(self, type(self))
b = Bar()
b.foo()
print b.foo, b.__dict__['foo']
Certes, mais c'est de la triche. :-)
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
m (je
veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des objets
bien différents, si m est une méthode par exemple) ?
C'est à cause de
cette question que je trouvais que la phrase « m est un attribut de C »
n'avait pas de sens ; parce que je ne sais pas de quel objet Python du
programme on parle quand on dit "m".
Comme pour la majorité des "concepts" OO, il n'y a en fait aucune
définition universelle et non-ambigüe du terme "attribut". Si on se
tient au contexte spécifique du modèle objet de Python, un objet A est
attribut d'un objet O si l'expression O.A est résolue - c'est à dire,
ne lève pas un AttributeError.
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
Est-ce un objet référencé par
l'identificateur A se trouvant dans un espace de nom particulier
Francois a écrit :Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
cf ci-dessus.Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Francois a écrit :
Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
cf ci-dessus.
Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Francois a écrit :Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase ?
Est-ce l'objet retourné par O.A ?
cf ci-dessus.Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Bruno Desthuilliers a écrit :Francois a écrit :Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
Ok, dans ce cas je suis 100% d'accord avec ta définition. :-)m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
C'est pour ça que je disais :
« "m attribut de C" : pas de sens.
"C.m attribut de C" : a un sens etc... »
En revanche, il me semble qu'il n'y a pas d'ambiguïté sur la
dénomination des objets. Pour moi, m représente un objet dont le nom 'm'
se trouve dans un des espace de noms du programme (en regardant d'abord
dans l'espace de noms de C, puis en «remontant» les espaces de noms
jusqu'à ce que le nom 'm' soit trouvé ou pas)
tandis que C.m c'est C.m
si j'ose dire (l'objet retourné par l'expression "C.m" pour être précis).
Je dirais que la phrase "m est un attribut de C" est un raccourci
pratique où m signifie l'objet C.m (et dès fois c'est le même objet que
m, mais des fois non).
Je trouve que l'ambiguïté se fait sentir surtout quand on veut signifier
qu'un attribut est «propre» à un objet ou est un attribut «tout-court» à
l'objet (accessible via l'objet), ambiguïté qui était à l'origine de ce
post d'ailleurs.
Je reprends l'expression «propre» qui tu avais employée
dans ta première réponse (et qui me plaît bien).
Finalement, je dirai ceci : (O et A sont des objets)
-------------
1) "L'objet O.A est un attribut de l'objet O" si et seulement si O.A ne
lève pas un AttributeError. Dans ce cas, on peut dire "A est un attribut
de O",
mais c'est un raccourci avec des non-dits.
2) "L'objet O.A est un attribut *propre* à l'objet O" si et seulement si
O.A ne lève pas un AttributeError et si le nom 'A' appartient à l'espace
de noms de l'objet A.
Dans ce cas, on peut dire "A est un attribut
*propre* à O", mais c'est un raccourci avec des non-dits.
Remarque : Dans le cas 2), l'attribut O.A *propre* à l'objet A n'est pas
forcément le même objet que O.__dict__['A'] ; si O est une classe et A
une méthode par exemple.
Ça se tient ça ? Le terme d'attribut *propre* à un objet est-il utilisé
en général ou c'est un terme comme ça ?
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase
? Est-ce l'objet retourné par O.A ?
cf ci-dessus.Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Oui, là aussi 100% d'accord.
Bruno Desthuilliers a écrit :
Francois a écrit :
Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
Ok, dans ce cas je suis 100% d'accord avec ta définition. :-)
m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
C'est pour ça que je disais :
« "m attribut de C" : pas de sens.
"C.m attribut de C" : a un sens etc... »
En revanche, il me semble qu'il n'y a pas d'ambiguïté sur la
dénomination des objets. Pour moi, m représente un objet dont le nom 'm'
se trouve dans un des espace de noms du programme (en regardant d'abord
dans l'espace de noms de C, puis en «remontant» les espaces de noms
jusqu'à ce que le nom 'm' soit trouvé ou pas)
tandis que C.m c'est C.m
si j'ose dire (l'objet retourné par l'expression "C.m" pour être précis).
Je dirais que la phrase "m est un attribut de C" est un raccourci
pratique où m signifie l'objet C.m (et dès fois c'est le même objet que
m, mais des fois non).
Je trouve que l'ambiguïté se fait sentir surtout quand on veut signifier
qu'un attribut est «propre» à un objet ou est un attribut «tout-court» à
l'objet (accessible via l'objet), ambiguïté qui était à l'origine de ce
post d'ailleurs.
Je reprends l'expression «propre» qui tu avais employée
dans ta première réponse (et qui me plaît bien).
Finalement, je dirai ceci : (O et A sont des objets)
-------------
1) "L'objet O.A est un attribut de l'objet O" si et seulement si O.A ne
lève pas un AttributeError. Dans ce cas, on peut dire "A est un attribut
de O",
mais c'est un raccourci avec des non-dits.
2) "L'objet O.A est un attribut *propre* à l'objet O" si et seulement si
O.A ne lève pas un AttributeError et si le nom 'A' appartient à l'espace
de noms de l'objet A.
Dans ce cas, on peut dire "A est un attribut
*propre* à O", mais c'est un raccourci avec des non-dits.
Remarque : Dans le cas 2), l'attribut O.A *propre* à l'objet A n'est pas
forcément le même objet que O.__dict__['A'] ; si O est une classe et A
une méthode par exemple.
Ça se tient ça ? Le terme d'attribut *propre* à un objet est-il utilisé
en général ou c'est un terme comme ça ?
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase
? Est-ce l'objet retourné par O.A ?
cf ci-dessus.
Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Oui, là aussi 100% d'accord.
Bruno Desthuilliers a écrit :Francois a écrit :Bruno Desthuilliers a écrit :
"m attribut de C" <=> C.m ne lève pas un AttributeError.
Ça me plaît bien comme définition.
Pourtant il y a un truc qui m'ennuie. Dans la partie gauche de
l'équivalence, quel objet est représenté par l'identificateur m ?
Celui retourné par l'évaluation de l'expression "C.m"
Ok, dans ce cas je suis 100% d'accord avec ta définition. :-)m (je veux dire par là C.__dict__['m']) ou C.m (qui peuvent être des
objets bien différents, si m est une méthode par exemple) ?
C'est à cause de cette question que je trouvais que la phrase « m est
un attribut de C » n'avait pas de sens ; parce que je ne sais pas de
quel objet Python du programme on parle quand on dit "m".
C'est effectivement un poil flou et ambigü. Il faudrait utiliser deux
termes distincts, un pour C.m et l'autre pour C.__dict__['m'].
C'est pour ça que je disais :
« "m attribut de C" : pas de sens.
"C.m attribut de C" : a un sens etc... »
En revanche, il me semble qu'il n'y a pas d'ambiguïté sur la
dénomination des objets. Pour moi, m représente un objet dont le nom 'm'
se trouve dans un des espace de noms du programme (en regardant d'abord
dans l'espace de noms de C, puis en «remontant» les espaces de noms
jusqu'à ce que le nom 'm' soit trouvé ou pas)
tandis que C.m c'est C.m
si j'ose dire (l'objet retourné par l'expression "C.m" pour être précis).
Je dirais que la phrase "m est un attribut de C" est un raccourci
pratique où m signifie l'objet C.m (et dès fois c'est le même objet que
m, mais des fois non).
Je trouve que l'ambiguïté se fait sentir surtout quand on veut signifier
qu'un attribut est «propre» à un objet ou est un attribut «tout-court» à
l'objet (accessible via l'objet), ambiguïté qui était à l'origine de ce
post d'ailleurs.
Je reprends l'expression «propre» qui tu avais employée
dans ta première réponse (et qui me plaît bien).
Finalement, je dirai ceci : (O et A sont des objets)
-------------
1) "L'objet O.A est un attribut de l'objet O" si et seulement si O.A ne
lève pas un AttributeError. Dans ce cas, on peut dire "A est un attribut
de O",
mais c'est un raccourci avec des non-dits.
2) "L'objet O.A est un attribut *propre* à l'objet O" si et seulement si
O.A ne lève pas un AttributeError et si le nom 'A' appartient à l'espace
de noms de l'objet A.
Dans ce cas, on peut dire "A est un attribut
*propre* à O", mais c'est un raccourci avec des non-dits.
Remarque : Dans le cas 2), l'attribut O.A *propre* à l'objet A n'est pas
forcément le même objet que O.__dict__['A'] ; si O est une classe et A
une méthode par exemple.
Ça se tient ça ? Le terme d'attribut *propre* à un objet est-il utilisé
en général ou c'est un terme comme ça ?
Ok, mais j'aimerais juste savoir qui est l'objet A dans cette phrase
? Est-ce l'objet retourné par O.A ?
cf ci-dessus.Est-ce un objet référencé par l'identificateur A se trouvant dans un
espace de nom particulier
Pas nécessairement. Cet objet peut venir d'absolument n'importe où,
voire être créé dynamiquement lors de la résolution d'attribut (ce qui
est en général le cas des méthodes).
Oui, là aussi 100% d'accord.
Pour quelle définition de "espace de nom" ?
Bon, ok, là je n'aide pas vraiment à clarifier le débat. Ceci étant,
c'est bien toute l'ambiguïté du terme "attribut" qui se révèle ici. Et
aussi le problème qu'il peut y avoir à vouloir appliquer des concepts
inadéquats à un modèle donné. Dans le cas de Python, on ne travaille
qu'avec des couples nom => référence.
Je trouve que l'ambiguïté se fait sentir surtout quand on veut
signifier qu'un attribut est «propre» à un objet ou est un attribut
«tout-court» à l'objet (accessible via l'objet), ambiguïté qui était à
l'origine de ce post d'ailleurs.
Ca va plus loin en fait, puisque le fait que C.m soit résolu par
C.__dict__['m'] (en d'autres termes : (C.m is C.__dict__['m']) == True)
ne rends pas l'objet accessible par l'une ou l'autre syntaxe dépendant
de C pour son cycle de vie.
En d'autres termes, quelque soit l'objet o
tel o is C.m and o is C.__dict__['m'] n'implique pas que del C ou
delattr(C, 'm') ou del C.__dict__['m'] aient pour résultats de terminer
le cycle de vie de o.
Je reprends l'expression «propre» qui tu avais employée dans ta
première réponse (et qui me plaît bien).
même un attribut "propre" à une instance n'appartient pas à cette instance.
Pour le moment, c'est un terme "comme ça". Et comme tu peux le
constater, plus on essaie de définir précisément, et plus c'est le bordel.
Oui, là aussi 100% d'accord.
Sans vouloir être méchant, que tu sois d'accord ou pas n'y change en
l'occurrence pas grand chose !-)
Pour quelle définition de "espace de nom" ?
Bon, ok, là je n'aide pas vraiment à clarifier le débat. Ceci étant,
c'est bien toute l'ambiguïté du terme "attribut" qui se révèle ici. Et
aussi le problème qu'il peut y avoir à vouloir appliquer des concepts
inadéquats à un modèle donné. Dans le cas de Python, on ne travaille
qu'avec des couples nom => référence.
Je trouve que l'ambiguïté se fait sentir surtout quand on veut
signifier qu'un attribut est «propre» à un objet ou est un attribut
«tout-court» à l'objet (accessible via l'objet), ambiguïté qui était à
l'origine de ce post d'ailleurs.
Ca va plus loin en fait, puisque le fait que C.m soit résolu par
C.__dict__['m'] (en d'autres termes : (C.m is C.__dict__['m']) == True)
ne rends pas l'objet accessible par l'une ou l'autre syntaxe dépendant
de C pour son cycle de vie.
En d'autres termes, quelque soit l'objet o
tel o is C.m and o is C.__dict__['m'] n'implique pas que del C ou
delattr(C, 'm') ou del C.__dict__['m'] aient pour résultats de terminer
le cycle de vie de o.
Je reprends l'expression «propre» qui tu avais employée dans ta
première réponse (et qui me plaît bien).
même un attribut "propre" à une instance n'appartient pas à cette instance.
Pour le moment, c'est un terme "comme ça". Et comme tu peux le
constater, plus on essaie de définir précisément, et plus c'est le bordel.
Oui, là aussi 100% d'accord.
Sans vouloir être méchant, que tu sois d'accord ou pas n'y change en
l'occurrence pas grand chose !-)
Pour quelle définition de "espace de nom" ?
Bon, ok, là je n'aide pas vraiment à clarifier le débat. Ceci étant,
c'est bien toute l'ambiguïté du terme "attribut" qui se révèle ici. Et
aussi le problème qu'il peut y avoir à vouloir appliquer des concepts
inadéquats à un modèle donné. Dans le cas de Python, on ne travaille
qu'avec des couples nom => référence.
Je trouve que l'ambiguïté se fait sentir surtout quand on veut
signifier qu'un attribut est «propre» à un objet ou est un attribut
«tout-court» à l'objet (accessible via l'objet), ambiguïté qui était à
l'origine de ce post d'ailleurs.
Ca va plus loin en fait, puisque le fait que C.m soit résolu par
C.__dict__['m'] (en d'autres termes : (C.m is C.__dict__['m']) == True)
ne rends pas l'objet accessible par l'une ou l'autre syntaxe dépendant
de C pour son cycle de vie.
En d'autres termes, quelque soit l'objet o
tel o is C.m and o is C.__dict__['m'] n'implique pas que del C ou
delattr(C, 'm') ou del C.__dict__['m'] aient pour résultats de terminer
le cycle de vie de o.
Je reprends l'expression «propre» qui tu avais employée dans ta
première réponse (et qui me plaît bien).
même un attribut "propre" à une instance n'appartient pas à cette instance.
Pour le moment, c'est un terme "comme ça". Et comme tu peux le
constater, plus on essaie de définir précisément, et plus c'est le bordel.
Oui, là aussi 100% d'accord.
Sans vouloir être méchant, que tu sois d'accord ou pas n'y change en
l'occurrence pas grand chose !-)