PEP 645: Resolve unreferenced footnotes (#3253)
This commit is contained in:
Adam Turner
GitHub
parent
8d08b74983
commit
e083c4e1bd
69
pep-0645.rst
69
pep-0645.rst
|
|
@ -46,10 +46,10 @@ Types in Python can be quite verbose, this can be a hindrance when working towar
|
|||
as was done with the Union type in :pep:`604` (e.g., int | str), would reduce the effort needed to add types to new and existing Python code.
|
||||
The Optional annotation is used frequently in both partially and fully typed Python code bases. In a small sampling of `5 well-typed open
|
||||
source projects, on average 7% of annotations
|
||||
<https://gist.github.com/MaggieMoss/fd8dfe002b2702fae243dbf81a62624e>`_ [2] included at least one optional type. This indicates
|
||||
<https://gist.github.com/MaggieMoss/fd8dfe002b2702fae243dbf81a62624e>`_ included at least one optional type. This indicates
|
||||
that updating the syntax has the potential to make types more concise, reduce code length and improve readability.
|
||||
|
||||
Simplifying the syntax for optionals has been `discussed previously <https://github.com/python/typing/issues/429>`_ [3] within the typing community.
|
||||
Simplifying the syntax for optionals has been `discussed previously <https://github.com/python/typing/issues/429>`_ within the typing community.
|
||||
The consensus during these conversations has been that ``?`` is the preferred operator. There is no native support for unary ``?`` in Python and this will
|
||||
need to be added to the runtime.
|
||||
|
||||
|
|
@ -67,13 +67,15 @@ Should :pep:`505` be approved in the future, it would not interfere with the typ
|
|||
since all uses of the ``?`` would be conceptually related, it would not be confusing in terms of learning Python or a hindrance to quick visual comprehension.
|
||||
|
||||
The proposed syntax, with the postfix operator, mimics the optional syntax found in other typed languages, like C#, TypeScript and Swift.
|
||||
The widespread adoption and popularity of these languages means that Python developers are likely already familiar with this syntax.::
|
||||
The widespread adoption and popularity of these languages means that Python developers are likely already familiar with this syntax.
|
||||
|
||||
// Optional in Swift
|
||||
var example: String?
|
||||
.. code:: text
|
||||
|
||||
// Optional in C#
|
||||
string? example;
|
||||
// Optional in Swift
|
||||
var example: String?
|
||||
|
||||
// Optional in C#
|
||||
string? example;
|
||||
|
||||
Adding this syntax would also follow the often used pattern of using builtin types as annotations. For example, ``list``, ``dict`` and ``None``. This would allow more annotations to be
|
||||
added to Python code without importing from ``typing``.
|
||||
|
|
@ -84,44 +86,44 @@ Specification
|
|||
|
||||
The new optional syntax should be accepted for function, variable, attribute and parameter annotations.
|
||||
|
||||
::
|
||||
.. code:: text
|
||||
|
||||
# instead of
|
||||
# def foo(x: Optional[int], y: Optional[str], z: Optional[list[int]): ...
|
||||
def foo(x: int?, y: str?, x: list[int]?): ...
|
||||
# instead of
|
||||
# def foo(x: Optional[int], y: Optional[str], z: Optional[list[int]): ...
|
||||
def foo(x: int?, y: str?, x: list[int]?): ...
|
||||
|
||||
# def bar(x: list[typing.Optional[int]]): ...
|
||||
def bar(x: list[int?]): ...
|
||||
# def bar(x: list[typing.Optional[int]]): ...
|
||||
def bar(x: list[int?]): ...
|
||||
|
||||
The new optional syntax should be equivalent to the existing typing.Optional syntax
|
||||
|
||||
::
|
||||
.. code:: text
|
||||
|
||||
typing.Optional[int] == int?
|
||||
typing.Optional[int] == int?
|
||||
|
||||
The new optional syntax should have the same identity as the existing typing.Optional syntax.
|
||||
|
||||
::
|
||||
.. code:: text
|
||||
|
||||
typing.Optional[int] is int?
|
||||
typing.Optional[int] is int?
|
||||
|
||||
|
||||
It should also be equivalent to a Union with None.
|
||||
|
||||
::
|
||||
.. code:: text
|
||||
|
||||
# old syntax
|
||||
int? == typing.Union[int, None]
|
||||
# old syntax
|
||||
int? == typing.Union[int, None]
|
||||
|
||||
# new syntax
|
||||
int? == int | None
|
||||
# new syntax
|
||||
int? == int | None
|
||||
|
||||
Since the new Union syntax specified in :pep:`604` is supported in ``isinstance`` and ``issubclass``, the new optional syntax should be supported in both ``isinstance`` and ``issubclass``,
|
||||
|
||||
::
|
||||
.. code:: text
|
||||
|
||||
isinstance(1, int?) # true
|
||||
issubclass(Child, Super?) # true
|
||||
isinstance(1, int?) # true
|
||||
issubclass(Child, Super?) # true
|
||||
|
||||
A new dunder method will need to be implemented to allow the ``?`` operator to be overloaded for other functionality.
|
||||
|
||||
|
|
@ -145,24 +147,7 @@ Discussed alternatives were
|
|||
* A prefix operator (``?int``).
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [2] Use of Optional Annotations in Open Source Python projects
|
||||
(https://gist.github.com/MaggieMoss/fd8dfe002b2702fae243dbf81a62624e)
|
||||
.. [3] Github Issue Discussion of Optional syntax
|
||||
(https://github.com/python/typing/issues/429)
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
sentence-end-double-space: t
|
||||
fill-column: 70
|
||||
coding: utf-8
|
||||
End:
|
||||
|
|
|
|||
Loading…
Reference in New Issue