This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: typing: tested TypeVar instance subclass TypeError is incidental
Type: enhancement Stage: patch review
Components: Library (Lib) Versions:
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: AlexWaygood, GBeauregard, JelleZijlstra, kj, serhiy.storchaka, sobolevn
Priority: normal Keywords: patch

Created on 2022-02-04 21:59 by GBeauregard, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 31148 open GBeauregard, 2022-02-05 18:45
Messages (7)
msg412544 - (view) Author: Gregory Beauregard (GBeauregard) * Date: 2022-02-04 21:59

typing's testcases contain the following test to ensure instances of TypeVar cannot be subclassed:

def test_cannot_subclass_vars(self):
    with self.assertRaises(TypeError):
        class V(TypeVar('T')):

The reason this raises a TypeError is incidental and subject to behavior change, not because doing so is prohibited per se; what's happening is the class creation does the equivalent of type(TypeVar('T')(name, bases, namespace), but this calls TypeVar's __init__ function with these items as the TypeVar constraints. TypeVar runs typing._type_check on the type constraints passed to it, and the literals for the namespace/name do not pass the callable() check in typing._type_check, causing it to raise a TypeError. I find it dubious this is the behavior the testcase is intending to test and the error it gives is confusing

I propose we add __mro_entries__ to the TypeVar class that only contains a raise of TypeError to properly handle this case

I can write this patch
msg412589 - (view) Author: Gregory Beauregard (GBeauregard) * Date: 2022-02-05 18:45
The reason this test passed before is a bit confusing. Run the following code standalone to see where the type(TypeVar('T'))(name, bases, namespace) check is coming from.
class TypeVar:
    def __init__(self, name, *constraints):
        # in actual TypeVar, each constraint is run through
        # typing._type_check, casuing TypeError via not callable() 

class V(TypeVar("T")):
msg412591 - (view) Author: Gregory Beauregard (GBeauregard) * Date: 2022-02-05 18:53
Fixing this test unblocks bpo-46644
msg412627 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2022-02-06 12:31
Note that instances of most other types are non-subclassable "by accident".

>>> class A(42): pass
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() takes at most 2 arguments (3 given)

>>> class B:
...     def __init__(self, *args): pass
>>> class C(B()): pass
>>> C
<__main__.B object at 0x7fdcfb49aae0>

It is okay until we decide that there is a problem, and it that case it would require more general solution.

Are there any issues with this in real code?
msg412646 - (view) Author: Gregory Beauregard (GBeauregard) * Date: 2022-02-06 17:25
The issue in real code I had in mind was internal to cpython: if we remove the callable() check from _type_check naively, this test starts to fail. Both of our proposed changes happen to not fail this check. Given your second example, would you prefer if we remove this testcase if the issue comes up in the final proposed patches? On the other hand, there is precedent for giving this a nice error message other places in
msg412661 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2022-02-06 20:14
The test is good. If we accidentally make a TypeVar instance subclassable, it will catch such error.
msg414970 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2022-03-12 03:39
This still behaves similarly after the bpo-46642 fix:

>>> class V(TypeVar("T")): pass
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jelle/py/cpython/Lib/", line 906, in __init__
    self.__constraints__ = tuple(_type_check(t, msg) for t in constraints)
  File "/Users/jelle/py/cpython/Lib/", line 906, in <genexpr>
    self.__constraints__ = tuple(_type_check(t, msg) for t in constraints)
  File "/Users/jelle/py/cpython/Lib/", line 189, in _type_check
    raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: TypeVar(name, constraint, ...): constraints must be types. Got (~T,).
Date User Action Args
2022-04-11 14:59:55adminsetgithub: 90800
2022-03-12 03:39:46JelleZijlstrasetmessages: + msg414970
2022-02-06 20:14:07serhiy.storchakasetmessages: + msg412661
2022-02-06 17:25:28GBeauregardsetmessages: + msg412646
2022-02-06 12:31:53serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg412627
2022-02-05 20:43:28gvanrossumsetnosy: - gvanrossum
2022-02-05 18:53:11GBeauregardsetmessages: + msg412591
2022-02-05 18:45:31GBeauregardsetkeywords: + patch
stage: patch review
pull_requests: + pull_request29324
2022-02-05 18:45:04GBeauregardsetmessages: + msg412589
2022-02-04 21:59:21GBeauregardcreate