PEP 728: Fix formatting and code highlighting issues (#3659)
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This commit is contained in:
parent
54ba2b4612
commit
15135035de
|
@ -12,8 +12,6 @@ Python-Version: 3.13
|
|||
Post-History: `09-Feb-2024 <https://discuss.python.org/t/pep-728-typeddict-with-typed-extra-items/45443>`__,
|
||||
|
||||
|
||||
.. highlight:: rst
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
@ -286,17 +284,17 @@ added in a subclass, all of the following conditions should apply:
|
|||
|
||||
- If ``__extra__`` is read-only
|
||||
|
||||
- The item can be either required or non-required
|
||||
- The item can be either required or non-required
|
||||
|
||||
- The item's value type is consistent with ``T``
|
||||
- The item's value type is consistent with ``T``
|
||||
|
||||
- If ``__extra__`` is not read-only
|
||||
|
||||
- The item is non-required
|
||||
- The item is non-required
|
||||
|
||||
- The item's value type is consistent with ``T``
|
||||
- The item's value type is consistent with ``T``
|
||||
|
||||
- ``T`` is consistent with the item's value type
|
||||
- ``T`` is consistent with the item's value type
|
||||
|
||||
- If ``__extra__`` is not redeclared, the subclass inherits it as-is.
|
||||
|
||||
|
@ -337,19 +335,19 @@ infinite set of items that all satisfy the following conditions:
|
|||
|
||||
- If ``__extra__`` is read-only
|
||||
|
||||
- The key's value type is consistent with ``T``
|
||||
- The key's value type is consistent with ``T``
|
||||
|
||||
- The key is not in ``S``.
|
||||
- The key is not in ``S``.
|
||||
|
||||
- If ``__extra__`` is not read-only
|
||||
|
||||
- The key is non-required
|
||||
- The key is non-required
|
||||
|
||||
- The key's value type is consistent with ``T``
|
||||
- The key's value type is consistent with ``T``
|
||||
|
||||
- ``T`` is consistent with the key's value type
|
||||
- ``T`` is consistent with the key's value type
|
||||
|
||||
- The key is not in ``S``.
|
||||
- The key is not in ``S``.
|
||||
|
||||
For type checking purposes, let ``__extra__`` be a non-required pseudo-item to
|
||||
be included whenever "for each ... item/key" is stated in
|
||||
|
@ -362,25 +360,25 @@ and we modify it as follows:
|
|||
|
||||
* For each item in ``B``, ``A`` has the corresponding key, unless the item
|
||||
in ``B`` is read-only, not required, and of top value type
|
||||
(``ReadOnly[NotRequired[object]]``). [Edit: Otherwise, if the
|
||||
(``ReadOnly[NotRequired[object]]``). **[Edit: Otherwise, if the
|
||||
corresponding key with the same name cannot be found in ``A``, "__extra__"
|
||||
is considered the corresponding key.]
|
||||
is considered the corresponding key.]**
|
||||
|
||||
* For each item in ``B``, if ``A`` has the corresponding key [Edit: or
|
||||
"__extra__"], the corresponding value type in ``A`` is consistent with the
|
||||
* For each item in ``B``, if ``A`` has the corresponding key **[Edit: or
|
||||
"__extra__"]**, the corresponding value type in ``A`` is consistent with the
|
||||
value type in ``B``.
|
||||
|
||||
* For each non-read-only item in ``B``, its value type is consistent with
|
||||
the corresponding value type in ``A``. [Edit: if the corresponding key
|
||||
the corresponding value type in ``A``. **[Edit: if the corresponding key
|
||||
with the same name cannot be found in ``A``, "__extra__" is considered the
|
||||
corresponding key.]
|
||||
corresponding key.]**
|
||||
|
||||
* For each required key in ``B``, the corresponding key is required in ``A``.
|
||||
For each non-required key in ``B``, if the item is not read-only in ``B``,
|
||||
the corresponding key is not required in ``A``.
|
||||
[Edit: if the corresponding key with the same name cannot be found in
|
||||
**[Edit: if the corresponding key with the same name cannot be found in
|
||||
``A``, "__extra__" is considered to be non-required as the corresponding
|
||||
key.]
|
||||
key.]**
|
||||
|
||||
The following examples illustrate these checks in action.
|
||||
|
||||
|
@ -412,7 +410,7 @@ corresponding key. ``"year"`` being required violates the rule "For each
|
|||
required key in ``B``, the corresponding key is required in ``A``".
|
||||
|
||||
When ``__extra__`` is defined to be read-only in a TypedDict type, it is possible
|
||||
for an item to have a narrower type than ``__extra__``'s value type.
|
||||
for an item to have a narrower type than ``__extra__``'s value type::
|
||||
|
||||
class Movie(TypedDict):
|
||||
name: str
|
||||
|
@ -450,7 +448,7 @@ Interaction with Mapping[KT, VT]
|
|||
A TypedDict type can be consistent with ``Mapping[KT, VT]`` types other than
|
||||
``Mapping[str, object]`` as long as the union of value types on the TypedDict
|
||||
type is consistent with ``VT``. It is an extension of this rule from the typing
|
||||
spec::
|
||||
spec:
|
||||
|
||||
* A TypedDict with all ``int`` values is not consistent with
|
||||
``Mapping[str, int]``, since there may be additional non-``int``
|
||||
|
@ -509,7 +507,7 @@ For example::
|
|||
regular_dict: dict[str, int] = not_required_num # OK
|
||||
f(not_required_num) # OK
|
||||
|
||||
In this case, methods that are previously unavailable on a TypedDict are allowed.
|
||||
In this case, methods that are previously unavailable on a TypedDict are allowed::
|
||||
|
||||
not_required_num.clear() # OK
|
||||
|
||||
|
@ -631,7 +629,7 @@ Acknowledgments
|
|||
|
||||
Thanks to Jelle Zijlstra for sponsoring this PEP and providing review feedback,
|
||||
Eric Traut who `proposed the original design
|
||||
<https://mail.python.org/archives/list/typing-sig@python.org/message/3Z72OQWVTOVS6UYUUCCII2UZN56PV5II/>`
|
||||
<https://mail.python.org/archives/list/typing-sig@python.org/message/3Z72OQWVTOVS6UYUUCCII2UZN56PV5II/>`__
|
||||
this PEP iterates on, and Alice Purcell for offering their perspective as the
|
||||
author of :pep:`705`.
|
||||
|
||||
|
|
Loading…
Reference in New Issue