Le mardi 27 juin 2006 05:38, Phillip J. Eby a écrit :
At 05:16 PM 6/26/2006 -0700, Martin Maly wrote:
class D(object):
... def getclass(self):
... print D.getclass
... return C
... __class__ = property(getclass)
...
isinstance(D(), D)
True
Phillip J. Eby wrote:
It seems that the __class__ is only accessed in some cases, but not
always, leading to what I think is a semantic inconsistency.
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
Martin Maly wrote:
Thanks for the response. The code snippet I sent deals with new style
classes only so I assume that in some cases isinstance falls back to
old-style-like handling which then asks for __bases__ and __class__
etc, possibly incorrectly so on new style classes.
Again, I believe
At 10:13 PM 6/26/2006 -0700, Guido van Rossum wrote:
On 6/26/06, Greg Ewing [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
__class__.
If this is a
At 09:29 AM 6/27/2006 +0200, Maric Michaud wrote:
Le mardi 27 juin 2006 05:38, Phillip J. Eby a écrit :
As it happens, this is due to the fact that E is a type, while E() is
not. There's an optimization in the isinstance() machinery that simply
checks to see if D().__class__ is a subtype of
At 02:49 PM 6/27/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
It seems that the __class__ is only accessed in some cases, but not
always, leading to what I think is a semantic inconsistency.
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in
Martin v. Löwis wrote:
Again, I believe this is all included for ExtensionClasses: it looks
for __class__ on the object if the type check fails, so that an
ExtensionClass could be actually a class derived from the C type.
Now that we have had new-style classes for quite a
while, is there
At 12:02 PM 6/28/2006 +1200, Greg Ewing wrote:
Martin v. Löwis wrote:
Again, I believe this is all included for ExtensionClasses: it looks
for __class__ on the object if the type check fails, so that an
ExtensionClass could be actually a class derived from the C type.
Now that we have had
Hello Python Dev,
I am trying to understand the correct semantic of the isinstance built-in
function and while doing so, I came across few cases which raise some questions.
1) First example - a class instance pretends to have different class via
__class__.
class D(object):
... def
Martin Maly wrote:
isinstance(D(), D)
True
isinstance(D(), C)
D.getclass
True
This looks like a new/old class thing. Presumably once
everything is changed over to new-style classes, this
inconsistency will go away. And from the current behaviour,
it looks like __class__ and __bases__
Message-
From: Greg Ewing [mailto:[EMAIL PROTECTED]
Sent: Monday, June 26, 2006 8:00 PM
To: Martin Maly
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Semantic of isinstance
Martin Maly wrote:
isinstance(D(), D)
True
isinstance(D(), C)
D.getclass
True
This looks like a new/old
At 05:16 PM 6/26/2006 -0700, Martin Maly wrote:
class D(object):
... def getclass(self):
... print D.getclass
... return C
... __class__ = property(getclass)
...
isinstance(D(), D)
True
isinstance(D(), C)
D.getclass
True
isinstance in this case returns True to both C
Phillip J. Eby wrote:
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
__class__.
If this is a deliberate feature, it's a bit patchy, because
it means the proxy can't lie about *not* being an instance
of
On 6/26/06, Greg Ewing [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
__class__.
If this is a deliberate feature, it's a bit patchy, because
it means the
14 matches
Mail list logo
