Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate unusual ways of creating typing.NamedTuple classes #105566

Closed
AlexWaygood opened this issue Jun 9, 2023 · 0 comments · Fixed by #105609
Closed

Deprecate unusual ways of creating typing.NamedTuple classes #105566

AlexWaygood opened this issue Jun 9, 2023 · 0 comments · Fixed by #105609
Assignees
Labels
3.13 new features, bugs and security fixes stdlib Python modules in the Lib dir topic-typing type-feature A feature request or enhancement

Comments

@AlexWaygood
Copy link
Member

AlexWaygood commented Jun 9, 2023

Feature or enhancement

I propose that we deprecate in Python 3.13 the following unusual ways of constructing a typing.NamedTuple:

from typing import NamedTuple

Foo = NamedTuple("Foo", x=int, y=int)  # NamedTuple with "x" and "y" fields
Bar = NamedTuple("Bar")                # empty NamedTuple
Baz = NamedTuple("Baz", None)          # empty NamedTuple
Eggs = NamedTuple("Eggs", fields=None) # empty NamedTuple

Pitch

typing.NamedTuple has been around for quite a while now, but none of the above methods of constructing NamedTuples are supported by type checkers. If they're still unsupported by type checkers after all this time, they're unlikely to ever be supported by type checkers.

Deprecating, and eventually removing, these ways of constructing NamedTuples will allow us to simplify the code at runtime. It will also be less confusing for users. Every way in which the runtime and type checkers differ in behaviour is a potential point of confusion for users; in general, we should work to keep these points of difference to a minimum.

These methods of constructing NamedTuples are not commonly seen in the wild. They're also pretty redundant -- if you want to construct a NamedTuple in one line, in a single function call, you can do it like this, which is supported by type checkers:

Foo = NamedTuple("Foo", [("x", int), ("y", int)])

If you want to construct an empty NamedTuple, meanwhile, you can do it in one of the following two ways, which are both supported by type checkers:

Bar = NamedTuple("Bar", [])
class Baz(NamedTuple): ...

Previous discussion

For very similar reasons, we previously deprecated and removed the keyword-argument syntax for creating TypedDicts. This was deprecated in 3.11, and removed in 3.13:

Linked PRs

@AlexWaygood AlexWaygood added type-feature A feature request or enhancement stdlib Python modules in the Lib dir topic-typing 3.13 new features, bugs and security fixes labels Jun 9, 2023
@AlexWaygood AlexWaygood changed the title Deprecate unusual ways of constructing NamedTuples Deprecate unusual ways of creating typing.NamedTuple classes Jun 9, 2023
AlexWaygood added a commit to AlexWaygood/cpython that referenced this issue Jun 9, 2023
@AlexWaygood AlexWaygood self-assigned this Jun 10, 2023
AlexWaygood added a commit that referenced this issue Jun 14, 2023
…sses (#105609)

Deprecate creating a typing.NamedTuple class using keyword arguments to denote the fields (`NT = NamedTuple("NT", x=int, y=str)`). This will be disallowed in Python 3.15. Use the class-based syntax or the functional syntax instead.

Two methods of creating `NamedTuple` classes with 0 fields using the functional syntax are also deprecated, and will be disallowed in Python 3.15: `NT = NamedTuple("NT")` and `NT = NamedTuple("NT", None)`. To create a `NamedTuple` class with 0 fields, either use `class NT(NamedTuple): pass` or `NT = NamedTuple("NT", [])`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 new features, bugs and security fixes stdlib Python modules in the Lib dir topic-typing type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant