Raymond Hettinger schrieb:
[Greg Ewing]
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B's __bases__
attribute is searched...
This
Georg Brandl wrote:
Since I cannot imagine a scenario where you would want to have non-classes
as the arguments of issubclass(),
I had one today, which is what led me to discover this.
I'm working on a Python-Ruby bridge that wraps Ruby
objects and classes in Python objects.
I wanted to make
Greg Ewing wrote:
Georg Brandl wrote:
Since I cannot imagine a scenario where you would want to have
non-classes
as the arguments of issubclass(),
I had one today, which is what led me to discover this.
I'm working on a Python-Ruby bridge that wraps Ruby
objects and classes in Python
Terry Reedy wrote:
The new (in 3.0 and maybe 2.6, but undocumented) special methods
__instancecheck__ and __subclasscheck__ let one overload the default
behavior of isinstance and issubclass.
That's fine for 3.0, but I don't think the current behaviour
should be removed from any 2.x version,
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B‘s __bases__
attribute is searched...
This suggests that issubclass(A, A) will always be
[Greg Ewing]
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B‘s __bases__
attribute is searched...
This suggests that issubclass(A, A)
Raymond Hettinger wrote:
This smells like a bug that brings issubclass() out of sync with
isinstance().
No, it affects both isinstance() and issubclass().
They both raise a TypeError if the purported class
object doesn't have a __bases__ attribute that is
a tuple.
This isn't necessarily
