Repository navigation
Can't create generic NamedTuple as of py3.9 #88089
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-04-23.16:22:56.566>
labels = ['type-bug', '3.9', '3.10', '3.11']
title = "Can't create generic NamedTuple as of py3.9"
updated_at = <Date 2022-03-10.21:38:13.215>
user = 'https://github.com/FHTMitchell'bugs.python.org fields:
activity = <Date 2022-03-10.21:38:13.215>
actor = 'behackett'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2021-04-23.16:22:56.566>
creator = 'FHTMitchell'
dependencies = []
files = []
hgrepos = []
issue_num = 43923
keywords = ['patch']
message_count = 25.0
messages = ['391705', '406083', '406124', '414541', '414557', '414558', '414559', '414563', '414567', '414568', '414570', '414584', '414585', '414589', '414592', '414593', '414705', '414709', '414754', '414791', '414792', '414815', '414816', '414817', '414830']
nosy_count = 16.0
nosy_names = ['gvanrossum', 'rhettinger', 'eric.smith', 'python-dev', 'serhiy.storchaka', 'graingert', 'levkivskyi', 'dlukes', 'JelleZijlstra', 'behackett', 'FHTMitchell', 'Steven Silvester', 'sobolevn', 'kj', 'AlexWaygood', 'juliusgeo']
pr_nums = ['31679', '31779', '31781']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue43923'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
FHTMitchell commented on Apr 23, 2021
As of python 3.9, you now can't have multiple inheritance with typing.NamedTuple subclasses. This seems sensible, until you realise that typing.Generic works via inheritance. This fails whether or not from __future__ import annotations is enabled.
example:
class Group(NamedTuple, Generic[T]): key: T group: List[T] --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-3-fc238c4826d7> in <module> ----> 1 class Group(NamedTuple, Generic[T]): 2 key: T 3 group: List[T] 4 ~/.conda/envs/py39/lib/python3.9/typing.py in _namedtuple_mro_entries(bases) 1818 def _namedtuple_mro_entries(bases): 1819 if len(bases) > 1: -> 1820 raise TypeError("Multiple inheritance with NamedTuple is not supported") 1821 assert bases[0] is NamedTuple 1822 return (_NamedTuple,) TypeError: Multiple inheritance with NamedTuple is not supportedThis worked fine in python 3.7 and 3.8 and as I understand it was one of the motivating cases for PEP-560.
The change was made as part of bpo-40185: Refactor typing.NamedTuple. Whilst the obvious alternative is "use dataclasses", they don't have the same runtime properties or implications as namedtuples.
dlukes commented on Nov 10, 2021
This is unfortunate, especially since it used to work... Going forward, is the intention not to support this use case? Or is it possible that support for generic NamedTuples will be re-added in the future?
rhettinger commented on Nov 10, 2021
+1 for reverting this change and restoring the previous behavior.
gvanrossum commented on Mar 4, 2022
Couldn't there be a subtler solution than rolling back #63570?
JelleZijlstra commented on Mar 5, 2022
Was this ever documented to work? We have now disallowed this behavior in 3.9 and 3.10 with few complaints, so it doesn't seem that important to restore it. Also, static type checkers generally disallow generic NamedTuples.
gvanrossum commented on Mar 5, 2022
Mypy seems to allow this:
It's true that pyright doesn't, but maybe that's because it doesn't work in 3.9-3.10?
JelleZijlstra commented on Mar 5, 2022
It doesn't really. If you do x = New([1], (2, 3)) you get:
main.py:11: error: List item 0 has incompatible type "int"; expected "T"
main.py:11: error: Argument 2 to "New" has incompatible type "Tuple[int, int]"; expected "Tuple[T, T]"
https://mypy-play.net/?mypy=latest&python=3.10&gist=a13c7a33c55a3aeee95324d46cd03ffd
23 remaining items
serhiy-storchaka commented on Apr 28, 2022
#92027 is a limited version of #31781 that only allows combining NamedTuple with Generic.
serhiy-storchaka commented on Apr 29, 2022
There is a problem related to the fact that tuple has the __class_getitem__ method. And if Generic[T] follows NamedTuple, it is tuple.__class_getitem__ called when subscript the type.
It is not specific to NamedTuple, this problem exists when you inherit from any generic class and Generic:
>>> from typing import * >>> T = TypeVar('T') >>> class A(tuple, Generic[T]): ... ... >>> class B(Generic[T], tuple): ... ... >>> A.__bases__ (<class 'tuple'>, <class 'typing.Generic'>) >>> B.__bases__ (<class 'typing.Generic'>, <class 'tuple'>) >>> A[int] __main__.A[int] >>> B[int] __main__.B[int] >>> type(A[int]) <class 'types.GenericAlias'> >>> type(B[int]) <class 'typing._GenericAlias'> >>> A[int, str] __main__.A[int, str] >>> B[int, str] Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/serhiy/py/cpython/Lib/typing.py", line 332, in inner return func(*args, **kwds) ^^^^^^^^^^^^^^^^^^^ File "/home/serhiy/py/cpython/Lib/typing.py", line 1767, in __class_getitem__ _check_generic(cls, params, len(cls.__parameters__)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/serhiy/py/cpython/Lib/typing.py", line 253, in _check_generic raise TypeError(f"Too {'many' if alen > elen else 'few'} arguments for {cls};" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: Too many arguments for <class '__main__.B'>; actual 2, expected 1And named tuple types are unexpectedly subscribtable without Generic (since they are tuple subclasses):
The problem is how to create non-generic (or generic with the specified parameters) subclasses of generic types.
JelleZijlstra commented on Apr 29, 2022
@serhiy-storchaka good catch! I'm not too concerned about non-generic subclasses of tuple being subscriptable. In general there are a lot of things you can do around annotations that are meaningless to type checkers, and we can just leave it to the static checkers to detect that.
But this does also affect NamedTuple with your PR:
That's pretty confusing behavior. (I guess this is why you added the "do not merge" label to #92027.)
What if we just do this?
Then things work as expected with either order for the base classes.
serhiy-storchaka commented on Apr 30, 2022
Consider the following example:
>>> import collections >>> from typing import * >>> T = TypeVar('T') >>> Group = collections.namedtuple('Group', 'key group')[T, list[T]]It looks somewhere like a generic named tuple. But it conflicts with what is proposed here.
gvanrossum commented on Apr 30, 2022
So that just inherits __class_getitem__ (CORRECTED) from tuple. Isn't it the job of the static checker to reject this? Runtime allows all kinds of nonsense, like list[int,int,int]. Is this any different?
gvanrossum commented on Apr 30, 2022
In any case if you want to make a class that isn't indexable but inherits from a class that is (e.g. namedtuple inheriting from tuple) you can just set __class_getitem__ = None in the class.
AlexWaygood commented on Apr 30, 2022
I agree with Guido.
serhiy-storchaka commented on May 1, 2022
#92106, #92107.
I have also opened a topic on Python-Dev about blessing the __dunder__ = None idiom: https://mail.python.org/archives/list/python-dev@python.org/thread/YGAK34DRWJFSIV2VZ4NC2J24XO37GCMM/
Un-parameterize `Rectangle`
Add a function to compute a radar grid that spans an input geocoded g…