[issue43923] Can't create generic NamedTuple as of py3.9

Change by Bernie Hackett : -- nosy: +behackett ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue43923] Can't create generic NamedTuple as of py3.9

Serhiy Storchaka added the comment: What about mix-ins or abstract base classes? class VecMixin: def length(self): return math.hypot(*self) class Vec2D(NamedTuple, VecMixin): x: float y: float class Vec3D(NamedTuple, VecMixin): x: float y: float z: float Curr

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: I agree with Jelle — a valid protocol cannot inherit from a concrete type, and the whole point of NamedTuple is that it creates a tuple subclass (and tuple is obviously a concrete type). -- ___ Python tracker

[issue43923] Can't create generic NamedTuple as of py3.9

Jelle Zijlstra added the comment: A NamedTuple that is also a Protocol doesn't make sense to me, since a NamedTuple is a concrete (nominal) type and a Protocol cannot inherit from a concrete type. If you want something like that to happen, it's better to open an issue on https://github.com/p

[issue43923] Can't create generic NamedTuple as of py3.9

Julius Park added the comment: What about Protocol? It is possible to create a dataclass that is a protocol, so it would be nicer from a symmetry perspective to allow it on both dataclasses and NamedTuples. -- ___ Python tracker

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: +1 for the more minimal changeset proposed in PR 31781. I've never felt a need for NamedTuple multiple inheritance other than with Generic, so wouldn't be opposed to restricting it only to Generic. -- ___ Python tra

[issue43923] Can't create generic NamedTuple as of py3.9

Serhiy Storchaka added the comment: PR 31781 is a simple PR which enables multiple inheritance with NamedTuple. As a side effect, it adds support of generic NamedTuple. I am not sure that all details work as expected. It is easy to limit multiple inheritance only for Generic if needed.

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Serhiy Storchaka : -- pull_requests: +29887 pull_request: https://github.com/python/cpython/pull/31781 ___ Python tracker ___

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Julius Park : -- nosy: +juliusgeo nosy_count: 14.0 -> 15.0 pull_requests: +29884 pull_request: https://github.com/python/cpython/pull/31779 ___ Python tracker ___ ___

[issue43923] Can't create generic NamedTuple as of py3.9

Steven Silvester added the comment: I agree we're stuck with the typing stub workaround for our use case. We can re-submit a "fix forward" PR. -- ___ Python tracker ___

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: Playing tricks where compile-time and run-time see slightly different types is probably more productive than trying to revert a PR that was in Python 3.9 and 3.10. :-) I'm not opposed to supporting generic NamedTuple, but I expect the fix will never hit 3

[issue43923] Can't create generic NamedTuple as of py3.9

Steven Silvester added the comment: The use case that prompted https://github.com/python/cpython/pull/31679 is that we are adding typings to `PyMongo`. We are late to using typings, because we only recently dropped Python 2.7 support. We have an existing options class that subclasses `Na

[issue43923] Can't create generic NamedTuple as of py3.9

Thomas Grainger added the comment: The main advantage for my usecase is support for heterogeneous unpacking On Sat, Mar 5, 2022, 6:04 PM Alex Waygood wrote: > > Alex Waygood added the comment: > > I sense we'll have to agree to disagree on the usefulness of NamedTuples > in the age of datacl

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: I sense we'll have to agree to disagree on the usefulness of NamedTuples in the age of dataclasses :) For me, I find the simplicity of the underlying idea behind namedtuples — "tuples with some properties bolted on" — very attractive. Yes, standard tuples are

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: Okay, that's a sensible use case. I do doubt your intuition of preferring named tuples over dataclasses a bit. This seems to encourage premature optimization. I'd say for simple cases use plain tuples (most performant), for complex cases use dataclasses (na

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Alex Waygood : -- nosy: +graingert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: Consider the typeshed stub for `concurrent.futures.DoneAndNotDoneFutures`. At runtime this is a `collections.namedtuple`, but in the stub, we need it to be generic to allow precise type inference. But we can't have a generic NamedTuple, so the stub is currentl

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: Can you be more specific about your use cases? -- ___ Python tracker ___ ___ Python-bugs-list m

[issue43923] Can't create generic NamedTuple as of py3.9

Serhiy Storchaka added the comment: Please don't revert all changes. It will not make it working right in any case. See issue44863 for more correct approach. -- ___ Python tracker __

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: > Is there an actual use case that broke? No, because this was never usable in the first place. But there are those who wish it were usable :) -- ___ Python tracker

[issue43923] Can't create generic NamedTuple as of py3.9

Alex Waygood added the comment: I actually have quite a few use cases for this feature. It's true that type checkers don't (yet) support it, but that doesn't mean that it should be disallowed at runtime. In fact, allowing it at runtime will surely give type checkers room to experiment with

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: So if it doesn't work in mypy why bother making it work at runtime? Is there an actual use case that broke? (There might be, but probably esoteric if nobody's run into it until now.) -- ___ Python tracker

[issue43923] Can't create generic NamedTuple as of py3.9

Jelle Zijlstra added the comment: 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

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: Mypy seems to allow this: from typing import NamedTuple, TypeVar, Generic, List, Tuple T = TypeVar("T") class New(NamedTuple, Generic[T]): x: List[T] y: Tuple[T, T] It's true that pyright doesn't, but maybe that's because it doesn't work in 3.9-3

[issue43923] Can't create generic NamedTuple as of py3.9

Jelle Zijlstra added the comment: 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. -- __

[issue43923] Can't create generic NamedTuple as of py3.9

Guido van Rossum added the comment: Couldn't there be a subtler solution than rolling back GH-19371? -- ___ Python tracker ___ ___

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Alex Waygood : -- nosy: +Jelle Zijlstra, gvanrossum, kj, sobolevn ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 7.0 -> 8.0 pull_requests: +29798 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31679 ___ Python tracker _

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Alex Waygood : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue43923] Can't create generic NamedTuple as of py3.9

Raymond Hettinger added the comment: +1 for reverting this change and restoring the previous behavior. -- ___ Python tracker ___ __

[issue43923] Can't create generic NamedTuple as of py3.9

David Lukeš added the comment: 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? -- nosy: +dlukes __

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue43923] Can't create generic NamedTuple as of py3.9

Change by Raymond Hettinger : -- nosy: +levkivskyi, rhettinger, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing

[issue43923] Can't create generic NamedTuple as of py3.9

Change by FHTMitchell : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue43923] Can't create generic NamedTuple as of py3.9

New submission from FHTMitchell : 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. exam