isinstance(anything, MetaclassThatDefinesInstancecheck) raises instead of returning False #46578

Activity

1. jyasskin commented on Mar 17, 2008

   

   jyasskinmannequin

   on Mar 17, 2008

   MannequinAuthor

   More actions

   >>> 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)
2. jyasskin

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Mar 17, 2008
3. werneck commented on May 2, 2008

   

   werneckmannequin

   on May 2, 2008

   Mannequin

   More actions

   In 3.0 it happens with any class. Just the cls argument missing on the
   call to instancecheck.
4. werneck commented on May 3, 2008

   

   werneckmannequin

   on May 3, 2008

   Mannequin

   More actions

   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
5. mato2000 commented on Jun 21, 2008

   

   mato2000mannequin

   on Jun 21, 2008

   Mannequin

   More actions

   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
6. zanella commented on Jun 30, 2008

   

   zanellamannequin

   on Jun 30, 2008

   Mannequin

   More actions

   So..., could this issue be closed ?
7. mato2000 commented on Jun 30, 2008

   

   mato2000mannequin

   on Jun 30, 2008

   Mannequin

   More actions

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

   closed this as completedon Jun 30, 2008
9. benjaminp

   added

   invalid

   on Jun 30, 2008
10. jyasskin commented on Jun 30, 2008

    

    jyasskinmannequin

    on Jun 30, 2008

    MannequinAuthor

    More actions

    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.
11. jyasskin

    reopened this on Jun 30, 2008
12. jyasskin

    removed

    invalid

    on Jun 30, 2008
13. amauryfa commented on Jun 30, 2008

    

    amauryfa

    on Jun 30, 2008

    Contributor

    More actions

    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.
14. devdanzin commented on May 13, 2009

    

    devdanzinmannequin

    on May 13, 2009

    Mannequin

    More actions

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

    closed this as completedon May 13, 2009
16. ezio-melotti

    transferred this issue fromon Apr 10, 2022