Description

AlexWaygood

opened on May 18, 2023

Issue body actions

Since Python 3.11, defining generic NamedTuples has been legal, like so:

>>> from typing import *
>>> T = TypeVar("T")
>>> class Foo(NamedTuple, Generic[T]):
...     x: T
>>>

However, using the new PEP-695 syntax for generic NamedTuples fails with a slightly inexplicable error message:

>>> from typing import *
>>> class Foo[T](NamedTuple):
...     x: T
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <generic parameters of Foo>
  File "C:\Users\alexw\coding\cpython\Lib\typing.py", line 2707, in __new__
    setattr(nm_tpl, key, ns[key])
AttributeError: attribute '__type_params__' of 'type' objects is not writable

Using PEP-695 syntax for generic TypedDicts seems to work fine, but isn't tested anywhere in test_typing.py, as far as I can tell:

>>> class Bar[T](TypedDict):
...     x: T
...
>>> Bar.__type_params__
(T,)
>>> Bar.__orig_bases__
(<function TypedDict at 0x0000017E9A17D9D0>, typing.Generic[T])
>>> Bar.__mro__
(<class '__main__.Bar'>, <class 'typing.Generic'>, <class 'dict'>, <class 'object'>)

Cc. @JelleZijlstra

Activity

1. AlexWaygood

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   topic-typing

   3.12only security fixesonly security fixes

   on May 18, 2023
2. JelleZijlstra

   self-assigned this

   on May 18, 2023
3. AlexWaygood commented on May 18, 2023

   

   AlexWaygood

   on May 18, 2023

   MemberAuthor

   More actions

   I guess we need to add __type_params__ to one of these two sets here?

   cpython/Lib/typing.py

   Lines 2668 to 2673 in cfa517d

   	# attributes prohibited to set in NamedTuple class syntax
   	_prohibited = frozenset({'__new__', '__init__', '__slots__', '__getnewargs__',
   	'_fields', '_field_defaults',
   	'_make', '_replace', '_asdict', '_source'})
   	_special = frozenset({'__module__', '__name__', '__annotations__'})
4. JelleZijlstra commented on May 18, 2023

   

   JelleZijlstra

   on May 18, 2023

   Member

   More actions

   Thanks! I'll take a look tonight (though feel free to propose a solution yourself if you can get to it earlier). Adding to _special feels like it's not enough, because that will just skip the assignment, and we still want the __type_params__ to end up on the generated class somehow.

   Reacted by Alex Waygood
5. AlexWaygood commented on May 18, 2023

   

   AlexWaygood

   on May 18, 2023

   MemberAuthor

   More actions

   Thanks! I'll take a look tonight (though feel free to propose a solution yourself if you can get to it earlier). Adding to _special feels like it's not enough, because that will just skip the assignment, and we still want the __type_params__ to end up on the generated class somehow.

   Ah. I agree that the generated class should have the correct __type_params__ value. And, I didn't realise that it wasn't possible to set the __type_params__ field on class objects. Maybe we should allow setting it on class objects, the same as you propose for function objects in #104600? I don't see a strong reason for it to be read-only; this case would benefit from it; and in general I feel like you should be able to mutate most fields on class objects
6. JelleZijlstra commented on May 18, 2023

   

   JelleZijlstra

   on May 18, 2023

   Member

   More actions

   Yes, it probably should be writable; I thought it already was. I can make that change.

   Reacted by Alex Waygood
7. JelleZijlstra commented on May 19, 2023

   

   JelleZijlstra

   on May 19, 2023

   Member

   More actions

   Fixed in #104634

   Reacted by Alex Waygood
8. JelleZijlstra

   closed this as completedon May 19, 2023

Issue actions