>>> class Meta(type):
...   def __instancecheck__(self, other):
...     return False
>>> isinstance(3, Meta)

In 2.6, this results in:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded while calling a Python object
(That's a recursion in C, through PyObject_IsInstance and
instancemethod_call)

In 3.0, I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __instancecheck__() takes exactly 2 positional arguments (1
given)

In 3.0 it happens with any class. Just the cls argument missing on the
call to instancecheck.

Seems like that's the wrong usage and the PEP-3119 notices that it's
hard to get the right semantics. To use it that way you need to define
the methods as a classmethod().

http://www.python.org/dev/peps/pep-3119/#one-trick-ponies

This is not a bug. Function __instancecheck__ should be a classmethod.

>>> class Meta(type):
...     @classmethod
...     def __instancecheck__(self, other):
...             return False
... 
>>> isinstance(3, Meta)
False

So..., could this issue be closed ?

Yes, it should be. I don't have permissions to.

I don't think so. It wouldn't be a bug if I wrote:

>>> class Meta(type):
...   def __instancecheck__(self, other):
...     return True
>>> isinstance(3, Meta)
... False

but it is a bug that the isinstance call raises an exception. If recent
builds no longer raise an exception, then the bug should be closed.

You guys also seem to have missed that the examples in PEP-3119 in fact
define __instancecheck__ as a normal method on a metaclass (which makes
it a classmethod on classes derived from that metaclass) instead of as a
classmethod on a metaclass.

I think the best is to ignore __instancecheck__ when
"cls.__instancecheck__" is returned as an unbound method. In this case,
we try "type(cls).__instancecheck__" instead.

Here is a patch along this idea.
I had to disable a test named "Evil", because in this case isinstance()
simply falls back to the original algorithm.

I don't know if this is applicable to 3.0: unbound methods don't exist
any more.

This now works correctly (returns False) in release26-maint, trunk and py3k.