Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
15 changes: 2 additions & 13 deletions docs/spec/literal.rst
Original file line number Diff line number Diff line change
Expand Up @@ -98,16 +98,16 @@ expressions, and nothing else.
Legal parameters for ``Literal`` at type check time
"""""""""""""""""""""""""""""""""""""""""""""""""""

``Literal`` may be parameterized with literal ints, byte and unicode strings,
``Literal`` may be parameterized with literal ints, strings, `bytes` objects,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency, maybe use the class names for int, str, bytes, and bool. With the proposed change, only bytes uses the actual class name.

Also, I think this requires double backticks.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Also ended up making the enum example more explicit.

bools, Enum values and ``None``. So for example, all of
the following would be legal::

Literal[26]
Literal[0x1A] # Exactly equivalent to Literal[26]
Literal[-4]
Literal["hello world"]
Literal[u"hello world"] # Exactly equivalent to Literal["hello world"]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend deleting "Exactly" here. Including it might be confusing. (I'm not sure how equivalency could be inexact. :) )

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this for consistency with a few lines up, but I'll remove it there too.

Literal[b"hello world"]
Literal[u"hello world"]
Literal[True]
Literal[Color.RED] # Assuming Color is some enum
Literal[None]
Expand Down Expand Up @@ -143,17 +143,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