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.

Author GBeauregard
Recipients AlexWaygood, GBeauregard, JelleZijlstra, gvanrossum, kj, sobolevn
Date 2022-02-04.21:59:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
In-reply-to
Content
https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_typing.py#L227-L230

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')):
            pass

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
History
Date User Action Args
2022-02-04 21:59:21GBeauregardsetrecipients: + GBeauregard, gvanrossum, JelleZijlstra, sobolevn, kj, AlexWaygood
2022-02-04 21:59:21GBeauregardsetmessageid: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
2022-02-04 21:59:21GBeauregardlinkissue46642 messages
2022-02-04 21:59:21GBeauregardcreate