[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

This still behaves similarly after the bpo-46642 fix:

>>> class V(TypeVar("T")): pass
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/jelle/py/cpython/Lib/typing.py", line 906, in __init__
self.__constraints__ = tuple(_type_check(t, msg) for t in constraints)
   ^^^
  File "/Users/jelle/py/cpython/Lib/typing.py", line 906, in 
self.__constraints__ = tuple(_type_check(t, msg) for t in constraints)
 ^^^
  File "/Users/jelle/py/cpython/Lib/typing.py", line 189, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
^^^
TypeError: TypeVar(name, constraint, ...): constraints must be types. Got (~T,).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The test is good. If we accidentally make a TypeVar instance subclassable, it 
will catch such error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Gregory Beauregard]

Gregory Beauregard  added the comment:

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 typing.py.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Note that instances of most other types are non-subclassable "by accident".

>>> class A(42): pass
... 
Traceback (most recent call last):
  File "", line 1, in 
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?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Gregory Beauregard]

Gregory Beauregard  added the comment:

Fixing this test unblocks bpo-46644

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Gregory Beauregard]

Change by Gregory Beauregard :


--
keywords: +patch
pull_requests: +29324
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31148

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Gregory Beauregard]

Gregory Beauregard  added the comment:

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() 
print(repr(constraints))

class V(TypeVar("T")):
pass
```

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

[Gregory Beauregard]

New submission from Gregory Beauregard :

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

--
components: Library (Lib)
messages: 412544
nosy: AlexWaygood, GBeauregard, Jelle Zijlstra, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: typing: tested TypeVar instance subclass TypeError is incidental
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com