Behaviour change in py312 for protocols with non-callable members and custom __subclasshook__ methods

[AlexWaygood]

Bug report

On Python 3.11:

>>> from typing import *
>>> @runtime_checkable
... class Foo(Protocol):
...     x = 1
...     @classmethod
...     def __subclasshook__(cls, other):
...         return hasattr(other, 'x')
...
>>> issubclass(object, Foo)
False

On Python 3.12:

>>> from typing import *
>>> @runtime_checkable
... class Foo(Protocol):
...     x = 1
...     @classmethod
...     def __subclasshook__(cls, other):
...         return hsattr(cls, 'x')
...
>>> issubclass(object, Foo)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\alexw\coding\cpython\Lib\typing.py", line 1829, in __subclasscheck__
    raise TypeError(
TypeError: Protocols with non-method members don't support issubclass()

I think I prefer the Python 3.11 behaviour here, since the whole point of allowing protocols to define custom __subclasshook__ methods is so that users can customise how issubclass() works on user-defined protocols.

Linked PRs

• gh-105974: Revert unintentional behaviour change for protocols with non-callable members and custom __subclasshook__ methods #105976
• [3.12] gh-105974: Revert unintentional behaviour change for protocols with non-callable members and custom __subclasshook__ methods (GH-105976) #106032

[AlexWaygood]

I think I prefer the Python 3.11 behaviour here, since the whole point of allowing protocols to define custom __subclasshook__ methods is so that users can customise how issubclass() works on user-defined protocols.

There is an argument that this behaviour change should be considered a feature rather than a bug. Mypy will complain about issubclass() checks against protocols with non-callable members, whether or not a custom __subclasshook__ method is defined: https://mypy-play.net/?mypy=latest&python=3.11&gist=83529c67737e01d8d837b700012e763b. It's good for the behaviour at runtime to closely reflect how type checkers understand Protocol wherever possible.

The "feature" where users can define custom __subclasshook__ methods on protocol classes is undocumented (and, apparently, untested). I think it was actually also unintentional, and only worked in Python <=3.11 because of some logic to ensure that concrete subclasses of protocol classes are able to define custom __subclasshook__ methods.

But the behaviour change in Python 3.12 was unintentional, and could break some users? I'm not sure really.

[AlexWaygood]

There is an argument that this behaviour change should be considered a feature rather than a bug.

@JelleZijlstra, thoughts on this? Is there a case to be made that the new behaviour should be considered a feature rather than a bug?

[JelleZijlstra]

I think the new behavior is a bug; we shouldn't be clobbering people's __subclasshook__ if they explicitly set one. It's fine if mypy rejects such classes as it's static, but the runtime can be more lenient.

[AlexWaygood]

SGTM