gh-101162: Forbid using issubclass with GenericAlias as the 1st arg

[sobolevn]

Now the implementation of types.GenericAlias and typing._GenericAlias is in line for this feature.

• Issue: issubclass() is inconsistent with generic aliases #101162

[AlexWaygood]

The change looks good to me. Strictly speaking, it's not backwards-compatible, but, as @serhiy-storchaka mentioned in the issue, it seems unlikely that anybody is passing a GenericAlias object as the first argument of an issubclass() call.

@Yhg1s, is it okay to make this change in 3.12? Or do we need a deprecation warning first?

[JelleZijlstra]

At this point I feel it's too late for 3.12: the feature freeze was extended only for pending PEPs, and this isn't one of them.

I feel we should go through a proper deprecation cycle here instead of just making the change. The behavior isn't completely unreasonable, so people may be relying on it.

[sobolevn]

At this point I feel it's too late for 3.12: the feature freeze was extended only for pending PEPs, and this isn't one of them.

Yeap, but I guess it is fine for 3.13 :)

I feel we should go through a proper deprecation cycle here instead of just making the change. The behavior isn't completely unreasonable, so people may be relying on it.

Hm, I don't quite agree. I think that this is just a regular bug (I think that it can even be backported). Here are my points:

1. First of all, typing._GenericAlias never worked this way. It raises:

>>> from typing import List
>>> issubclass(List[int], type)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class

So, we don't ever teach users to rely on this historically.

2. It is not documented, so it is not a promise.
3. It is not tested. Other interpreters also do not rely on it.
4. It only works for types using types.GenericAlias which are mostly builtin types. And most builtin types behave like this:

>>> list[int].__bases__
(<class 'object'>,)
>>> issubclass(list[int], object)
True
>>> issubclass(list[int], type)
False

Since most types just inherit from object (there are exceptions like _collections_abc.MappingView, AbstractContextManager, Queue subclasses, and some others).

5. I don't see realistical use-cases for this. Yes, it might be used. But, I don't think that it should be used in the first place.
6. Making a deprecation would make this more complicated in terms of code changes.

If you find my arguments not convincing enough, I am always happy to do a deprecation warning.

[sobolevn]

@serhiy-storchaka thanks for the review! Addressed.

[serhiy-storchaka]

That you for your contribution @sobolevn.

I do not think that a deprecation warning is needed here. This change could even be considered a bugfix and backported to 3.11 and 3.12, there there is no real need in this too.

Blacklisting __bases__ is a good method. I think that it may be worth to blacklist even more special attributes, or forbid them all, and use the white list to allow redirecting some special attributes. But this is a different issue.