As discussed in comments to #109544, the semantics of this attribute
are somewhat confusing. Add a note explaining its limitations and
steering users towards __required_keys__ and __optional_keys__ instead.
Deprecate two methods of creating typing.TypedDict classes with 0 fields using the functional syntax: `TD = TypedDict("TD")` and `TD = TypedDict("TD", None)`. Both will be disallowed in Python 3.15. To create a TypedDict class with 0 fields, either use `class TD(TypedDict): pass` or `TD = TypedDict("TD", {})`.
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", [])`.
Mostly, these are changes so that we use shorter sentences and shorter paragraphs. In particular, I've tried to make the first sentence introducing each object in the typing API short and declarative.
- AnyStr can be used in type annotations, contrary to the section header
- Unpack can also be used in annotations, and its use is not restricted
to generics. It makes more sense with other building blocks like Required.
- Protocol is not necessarily generic.
Also fix the indentation for two notes associated with Concatenate.
Split off from #104642, but I think this change is independently an
improvement.
* separate documentation and examples for both functions
* add examples demonstrating behaviour with unsupported types
* document return value of `get_origin` for `ParamSpecArgs` and `ParamSpecKwargs` instances
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
I'd like to make the fact that this does nothing at runtime
really obvious, since I suspect this is unintuitive for users who are
unfamiliar with static type checking.
I thought of this because of
https://discuss.python.org/t/add-arg-check-type-to-types/26384
wherein I'm skeptical that the user really did want `assert_type`.
Found some duplicate `to`s in the documentation and some code comments and fixed them.
[Misc/NEWS.d/3.12.0a1.rst](ed55c69ebd/Misc/NEWS.d/3.12.0a1.rst) also contains two duplicate `to`s, but I wasn't sure if it's ok to touch that file. Looks auto generated. I'm happy to amend the PR if requested. :)
Automerge-Triggered-By: GH:AlexWaygood
