pourrais-je avoir s'il vous plaît une explication sur cet exemple ? Deux
objets sont bel et bien différents, mais ont le même identifiant ?
Merci d'avance.
#----------------------------------------
>>> class MaClasse(object):
... def (self): print "bonjour"
... def g(self): print "Au revoir"
...
>>> MaClasse.f is MaClasse.g #les deux objets sont différents,
False
>>> id(MaClasse.f) == id(MaClasse.g) #mais ont le même id ?
True
#----------------------------------------
Les mêmes choses sont dîtes il me semble. Par contre, j'ai un petit problème de traduction. Dans le troisième message, il y a ceci :
« The returned object is a wrapper created on-the-fly as needed. You've requested two of them and each wrapper has a different object id but wraps an identical source. »
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
Francois a écrit :
Je viens de constater que la question a été évoquée sur comp.lang.python
ici :
Les mêmes choses sont dîtes il me semble. Par contre, j'ai un petit
problème de traduction. Dans le troisième message, il y a ceci :
« The returned object is a wrapper created on-the-fly as needed. You've
requested two of them and each wrapper has a different object id but
wraps an identical source. »
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
Les mêmes choses sont dîtes il me semble. Par contre, j'ai un petit problème de traduction. Dans le troisième message, il y a ceci :
« The returned object is a wrapper created on-the-fly as needed. You've requested two of them and each wrapper has a different object id but wraps an identical source. »
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
Francois
Bruno Desthuilliers a écrit :
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait peut-être un terme ad hoc spécifique en informatique. Car on y rencontre souvent ce terme.
-- François
Bruno Desthuilliers a écrit :
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait
peut-être un terme ad hoc spécifique en informatique. Car on y rencontre
souvent ce terme.
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait peut-être un terme ad hoc spécifique en informatique. Car on y rencontre souvent ce terme.
-- François
Pierre Maurette
Francois, le 19/08/2008 a écrit :
Bruno Desthuilliers a écrit :
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
Enveloppe, conteneur, voire coque ou coquille ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait peut-être un terme ad hoc spécifique en informatique. Car on y rencontre souvent ce terme.
Le terme ad hoc(*) spécifique en informatique est à mon avis "wrapper". Avec la typographie éventuellement souhaitable, à priori de l'italique, pour calmer les puristes. Ainsi, le francophone aura sur l'anglophone l'avantage d'une phrase plus claire, basée sur un vocabulaire enrichi et moins ambigu. "Dans l'emballage du colis, j'ai trouvé une enveloppe dans laquelle une note de Jules m'explique ce qu'il pense de mon idée de /wrapper/ du print."
(*) Existe-t-il un terme ad hoc pour "ad hoc" ?
-- Pierre Maurette
Francois, le 19/08/2008 a écrit :
Bruno Desthuilliers a écrit :
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
Enveloppe, conteneur, voire coque ou coquille ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait
peut-être un terme ad hoc spécifique en informatique. Car on y rencontre
souvent ce terme.
Le terme ad hoc(*) spécifique en informatique est à mon avis "wrapper".
Avec la typographie éventuellement souhaitable, à priori de l'italique,
pour calmer les puristes. Ainsi, le francophone aura sur l'anglophone
l'avantage d'une phrase plus claire, basée sur un vocabulaire enrichi
et moins ambigu.
"Dans l'emballage du colis, j'ai trouvé une enveloppe dans laquelle une
note de Jules m'explique ce qu'il pense de mon idée de /wrapper/ du
print."
Comment traduiriez vous le mot "wrapper" dans ces phrases ?
"emballage" ?
Enveloppe, conteneur, voire coque ou coquille ?
C'est ce que me donne mon dictionnaire, mais je me disais qu'il y avait peut-être un terme ad hoc spécifique en informatique. Car on y rencontre souvent ce terme.
Le terme ad hoc(*) spécifique en informatique est à mon avis "wrapper". Avec la typographie éventuellement souhaitable, à priori de l'italique, pour calmer les puristes. Ainsi, le francophone aura sur l'anglophone l'avantage d'une phrase plus claire, basée sur un vocabulaire enrichi et moins ambigu. "Dans l'emballage du colis, j'ai trouvé une enveloppe dans laquelle une note de Jules m'explique ce qu'il pense de mon idée de /wrapper/ du print."
(*) Existe-t-il un terme ad hoc pour "ad hoc" ?
-- Pierre Maurette
Bruno Desthuilliers
Francois a écrit :
Eric Brunel a écrit :
(snip)
Pour ce qui est effectivement construit par MaClasse.f, je laisse ça aux spécialiste(s) (au hasard, Bruno?).
C'est une question sur laquelle je me pencherai. Comme l'a dit Bruno, les descripteurs sont la base de l'orienté objet en Python.
Disons que pour les classes "new-style", les méthodes sont implémentées à l'aide du type function et du protocole descripteur. Je ne sais pas si ça fait du protocole descripteur la "base de l'oo en python", mais ça a l'élégance de rendre le tout très générique et très customisable.
Pour l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit un truc qui fait que f est liée à obj et que donc lorsqu'on applique la méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce serait facile à implémenter en pur Python :
class Method(object): def __init__(self, func, instance, cls): self.im_func = func self.im_self = instance self.im_class = cls def __call__(self, *args, **kw): # Q&D unbound method if self.im_self is None: im_self = args.pop(0) if not isinstance(im_self, self.cls): raise TypeError("unbound method yadda yadda") else: im_self = self.im_self return self.im_func(im_self, *args, **kw)
NB : le nommage n'est pas accidentel: >>> class Toto(object): ... def tata(self): pass ... >>> t = Toto() >>> meth = t.tata >>> meth <bound method Toto.tata of <__main__.Toto object at 0xb7c7fd2c>> >>> meth.im_self, meth.im_class, meth.im_func (<__main__.Toto object at 0xb7c7fd2c>, <class '__main__.Toto'>, <function tata at 0xb7c7a9cc>) >>>
Et c'est ainsi q'une fonction devient une méthode, n°2 : la mission !-)
Francois a écrit :
Eric Brunel a écrit :
(snip)
Pour ce qui est effectivement construit par MaClasse.f, je laisse ça
aux spécialiste(s) (au hasard, Bruno?).
C'est une question sur laquelle je me pencherai. Comme l'a dit Bruno,
les descripteurs sont la base de l'orienté objet en Python.
Disons que pour les classes "new-style", les méthodes sont implémentées
à l'aide du type function et du protocole descripteur. Je ne sais pas si
ça fait du protocole descripteur la "base de l'oo en python", mais ça a
l'élégance de rendre le tout très générique et très customisable.
Pour
l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit un
truc qui fait que f est liée à obj et que donc lorsqu'on applique la
méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du
paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce
serait facile à implémenter en pur Python :
class Method(object):
def __init__(self, func, instance, cls):
self.im_func = func
self.im_self = instance
self.im_class = cls
def __call__(self, *args, **kw):
# Q&D unbound method
if self.im_self is None:
im_self = args.pop(0)
if not isinstance(im_self, self.cls):
raise TypeError("unbound method yadda yadda")
else:
im_self = self.im_self
return self.im_func(im_self, *args, **kw)
NB : le nommage n'est pas accidentel:
>>> class Toto(object):
... def tata(self): pass
...
>>> t = Toto()
>>> meth = t.tata
>>> meth
<bound method Toto.tata of <__main__.Toto object at 0xb7c7fd2c>>
>>> meth.im_self, meth.im_class, meth.im_func
(<__main__.Toto object at 0xb7c7fd2c>, <class '__main__.Toto'>,
<function tata at 0xb7c7a9cc>)
>>>
Et c'est ainsi q'une fonction devient une méthode, n°2 : la mission !-)
Pour ce qui est effectivement construit par MaClasse.f, je laisse ça aux spécialiste(s) (au hasard, Bruno?).
C'est une question sur laquelle je me pencherai. Comme l'a dit Bruno, les descripteurs sont la base de l'orienté objet en Python.
Disons que pour les classes "new-style", les méthodes sont implémentées à l'aide du type function et du protocole descripteur. Je ne sais pas si ça fait du protocole descripteur la "base de l'oo en python", mais ça a l'élégance de rendre le tout très générique et très customisable.
Pour l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit un truc qui fait que f est liée à obj et que donc lorsqu'on applique la méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce serait facile à implémenter en pur Python :
class Method(object): def __init__(self, func, instance, cls): self.im_func = func self.im_self = instance self.im_class = cls def __call__(self, *args, **kw): # Q&D unbound method if self.im_self is None: im_self = args.pop(0) if not isinstance(im_self, self.cls): raise TypeError("unbound method yadda yadda") else: im_self = self.im_self return self.im_func(im_self, *args, **kw)
NB : le nommage n'est pas accidentel: >>> class Toto(object): ... def tata(self): pass ... >>> t = Toto() >>> meth = t.tata >>> meth <bound method Toto.tata of <__main__.Toto object at 0xb7c7fd2c>> >>> meth.im_self, meth.im_class, meth.im_func (<__main__.Toto object at 0xb7c7fd2c>, <class '__main__.Toto'>, <function tata at 0xb7c7a9cc>) >>>
Et c'est ainsi q'une fonction devient une méthode, n°2 : la mission !-)
Francois
Bruno Desthuilliers a écrit :
Pour l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit un truc qui fait que f est liée à obj et que donc lorsqu'on applique la méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce serait facile à implémenter en pur Python :
class Method(object): def __init__(self, func, instance, cls): self.im_func = func self.im_self = instance self.im_class = cls def __call__(self, *args, **kw): # Q&D unbound method if self.im_self is None: im_self = args.pop(0) if not isinstance(im_self, self.cls): raise TypeError("unbound method yadda yadda") else: im_self = self.im_self return self.im_func(im_self, *args, **kw)
Merci bien pour cet exemple d'implémentation 100% Python d'une classe Method. C'est assez éclairant pour moi. Je commence à comprendre un peu l'idée « méthode = objet qui enrobe une fonction »
-- François
Bruno Desthuilliers a écrit :
Pour l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit
un truc qui fait que f est liée à obj et que donc lorsqu'on applique
la méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du
paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce
serait facile à implémenter en pur Python :
class Method(object):
def __init__(self, func, instance, cls):
self.im_func = func
self.im_self = instance
self.im_class = cls
def __call__(self, *args, **kw):
# Q&D unbound method
if self.im_self is None:
im_self = args.pop(0)
if not isinstance(im_self, self.cls):
raise TypeError("unbound method yadda yadda")
else:
im_self = self.im_self
return self.im_func(im_self, *args, **kw)
Merci bien pour cet exemple d'implémentation 100% Python d'une classe
Method. C'est assez éclairant pour moi. Je commence à comprendre un peu
l'idée « méthode = objet qui enrobe une fonction »
Pour l'instant, je comprends qu'avec obj = MaClasse(), obj.f construit un truc qui fait que f est liée à obj et que donc lorsqu'on applique la méthode f à obj (obj.f()), on a pas besoin de préciser la valeur du paramètre self (obj en l'occurence) dans f.
Le "truc" en question s'appelle une instance de la classe method, et ce serait facile à implémenter en pur Python :
class Method(object): def __init__(self, func, instance, cls): self.im_func = func self.im_self = instance self.im_class = cls def __call__(self, *args, **kw): # Q&D unbound method if self.im_self is None: im_self = args.pop(0) if not isinstance(im_self, self.cls): raise TypeError("unbound method yadda yadda") else: im_self = self.im_self return self.im_func(im_self, *args, **kw)
Merci bien pour cet exemple d'implémentation 100% Python d'une classe Method. C'est assez éclairant pour moi. Je commence à comprendre un peu l'idée « méthode = objet qui enrobe une fonction »
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
-- François
Méta-MCI (MVP) a écrit :
Bonsoir !
Existe-t-il un terme ad hoc pour "ad hoc" ?
étudié pour ?
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle
est jolie cette expression et on comprend bien ce qu'elle veut dire, non
? Pourquoi vouloir une autre expression ?
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
-- François
Pierre Maurette
Francois, le 21/08/2008 a écrit :
Méta-MCI (MVP) a écrit :
Bonsoir !
Existe-t-il un terme ad hoc pour "ad hoc" ?
étudié pour ?
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un argument - elliptique - qui tend à peser dans le sens que " le terme ad hoc en informatique " pour "wrapper" est peut-être bien "wrapper". Comme "template" dans le même domaine, ou "weekend" et "al dente" dans d'autres.
-- Pierre Maurette
Francois, le 21/08/2008 a écrit :
Méta-MCI (MVP) a écrit :
Bonsoir !
Existe-t-il un terme ad hoc pour "ad hoc" ?
étudié pour ?
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est
jolie cette expression et on comprend bien ce qu'elle veut dire, non ?
Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un
argument - elliptique - qui tend à peser dans le sens que " le terme ad
hoc en informatique " pour "wrapper" est peut-être bien "wrapper".
Comme "template" dans le même domaine, ou "weekend" et "al dente" dans
d'autres.
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un argument - elliptique - qui tend à peser dans le sens que " le terme ad hoc en informatique " pour "wrapper" est peut-être bien "wrapper". Comme "template" dans le même domaine, ou "weekend" et "al dente" dans d'autres.
-- Pierre Maurette
Francois
Pierre Maurette a écrit :
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un argument - elliptique - qui tend à peser dans le sens que " le terme ad hoc en informatique " pour "wrapper" est peut-être bien "wrapper". Comme "template" dans le même domaine, ou "weekend" et "al dente" dans d'autres.
Ah pardon, je n'avais pas compris ça comme ça. Maintenant c'est clair.
Par contre, je ne suis pas tout à fait d'accord. Je ne suis pas non plus pour la traduction à tout prix dans les livres bien sûr car en informatique ce serait ridicule. En revanche, avoir une traduction dans un coin de la tête, c'est toujours appréciable, non ? Par exemple shell = coquille ou wrapper = enveloppe.
-- François
Pierre Maurette a écrit :
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle
est jolie cette expression et on comprend bien ce qu'elle veut dire,
non ? Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un
argument - elliptique - qui tend à peser dans le sens que " le terme ad
hoc en informatique " pour "wrapper" est peut-être bien "wrapper". Comme
"template" dans le même domaine, ou "weekend" et "al dente" dans d'autres.
Ah pardon, je n'avais pas compris ça comme ça. Maintenant c'est clair.
Par contre, je ne suis pas tout à fait d'accord. Je ne suis pas non plus
pour la traduction à tout prix dans les livres bien sûr car en
informatique ce serait ridicule. En revanche, avoir une traduction dans
un coin de la tête, c'est toujours appréciable, non ? Par exemple shell
= coquille ou wrapper = enveloppe.
Je ne comprends pas trop le problème avec l'expression "ad hoc". Elle est jolie cette expression et on comprend bien ce qu'elle veut dire, non ? Pourquoi vouloir une autre expression ?
Il n'y a aucun problème avec l'expression "ad hoc". La question est un argument - elliptique - qui tend à peser dans le sens que " le terme ad hoc en informatique " pour "wrapper" est peut-être bien "wrapper". Comme "template" dans le même domaine, ou "weekend" et "al dente" dans d'autres.
Ah pardon, je n'avais pas compris ça comme ça. Maintenant c'est clair.
Par contre, je ne suis pas tout à fait d'accord. Je ne suis pas non plus pour la traduction à tout prix dans les livres bien sûr car en informatique ce serait ridicule. En revanche, avoir une traduction dans un coin de la tête, c'est toujours appréciable, non ? Par exemple shell = coquille ou wrapper = enveloppe.
-- François
Méta-MCI \(MVP\)
Salut !
wrapper = enveloppe
Ou alors "wrapper => envelopper". Un verbe me semble mieux rendre le fait d'une action. Et, dans la série, wrapping => enveloppement.
Mais, perso, je serais assez tenté par "englober", que je comprends comme "entourer quelque chose, pour en faire un objet global".
Pour ad hoc, j'apprécie l'ellipse de Pierre Maurette, car il s'agit d'une expression latine. Et, donc, si on, accepte les locutions latines en français, pourquoi ne pas accepter des locutions anglaises ? Et franciser "to wrap" en "wrapper".
Bonne journée -- Michel Claveau
Salut !
wrapper = enveloppe
Ou alors "wrapper => envelopper". Un verbe me semble mieux rendre le
fait d'une action. Et, dans la série, wrapping => enveloppement.
Mais, perso, je serais assez tenté par "englober", que je comprends
comme "entourer quelque chose, pour en faire un objet global".
Pour ad hoc, j'apprécie l'ellipse de Pierre Maurette, car il s'agit
d'une expression latine. Et, donc, si on, accepte les locutions latines
en français, pourquoi ne pas accepter des locutions anglaises ? Et
franciser "to wrap" en "wrapper".
Ou alors "wrapper => envelopper". Un verbe me semble mieux rendre le fait d'une action. Et, dans la série, wrapping => enveloppement.
Mais, perso, je serais assez tenté par "englober", que je comprends comme "entourer quelque chose, pour en faire un objet global".
Pour ad hoc, j'apprécie l'ellipse de Pierre Maurette, car il s'agit d'une expression latine. Et, donc, si on, accepte les locutions latines en français, pourquoi ne pas accepter des locutions anglaises ? Et franciser "to wrap" en "wrapper".
