Skip to content

spec: various minor changes #2013

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/spec/generics.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2000,7 +2000,7 @@ Bound Rules
T1 = TypeVar("T1", bound=int)
TypeVar("Ok", default=T1, bound=float) # Valid
TypeVar("AlsoOk", default=T1, bound=int) # Valid
TypeVar("Invalid", default=T1, bound=str) # Invalid: int is not a subtype of str
TypeVar("Invalid", default=T1, bound=str) # Invalid: int is not assignable to str

Constraint Rules
^^^^^^^^^^^^^^^^
Expand Down
26 changes: 10 additions & 16 deletions docs/spec/literal.rst
Original file line number Diff line number Diff line change
Expand Up @@ -98,18 +98,23 @@ expressions, and nothing else.
Legal parameters for ``Literal`` at type check time
"""""""""""""""""""""""""""""""""""""""""""""""""""

``Literal`` may be parameterized with literal ints, byte and unicode strings,
bools, Enum values and ``None``. So for example, all of
``Literal`` may be parameterized with literal ``int``, ``str``, ``bytes``,
and ``bool`` objects, instances of ``enum.Enum`` subclasses, and ``None``. So for example, all of
the following would be legal::

Literal[26]
Literal[0x1A] # Exactly equivalent to Literal[26]
Literal[0x1A] # Equivalent to Literal[26]
Literal[-4]
Literal["hello world"]
Literal[u"hello world"] # Equivalent to Literal["hello world"]
Literal[b"hello world"]
Literal[u"hello world"]
Literal[True]
Literal[Color.RED] # Assuming Color is some enum

class Color(enum.Enum):
RED = 1
GREEN = 2

Literal[Color.RED]
Literal[None]

**Note:** Since the type ``None`` is inhabited by just a single
Expand Down Expand Up @@ -143,17 +148,6 @@ This should be exactly equivalent to the following type::

Literal[1, 2, 3, "foo", 5] | None

**Note:** String literal types like ``Literal["foo"]`` should subtype either
bytes or unicode in the same way regular string literals do at runtime.

For example, in Python 3, the type ``Literal["foo"]`` is equivalent to
``Literal[u"foo"]``, since ``"foo"`` is equivalent to ``u"foo"`` in Python 3.

Similarly, in Python 2, the type ``Literal["foo"]`` is equivalent to
``Literal[b"foo"]`` -- unless the file includes a
``from __future__ import unicode_literals`` import, in which case it would be
equivalent to ``Literal[u"foo"]``.

Illegal parameters for ``Literal`` at type check time
"""""""""""""""""""""""""""""""""""""""""""""""""""""

Expand Down
2 changes: 1 addition & 1 deletion docs/spec/tuples.rst
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ Type Compatibility Rules
------------------------

Because tuple contents are immutable, the element types of a tuple are covariant.
For example, ``tuple[int, int]`` is a subtype of ``tuple[float, complex]``.
For example, ``tuple[bool, int]`` is a subtype of ``tuple[int, object]``.

As discussed above, a homogeneous tuple of arbitrary length is equivalent
to a union of tuples of different lengths. That means ``tuple[()]``,
Expand Down