spec: various minor changes #2013
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Replace an incorrect use of "subtype" with "assignable" - Remove discussion of str/bytes Literal types that seems geared towards Python 2. Instead, say straightforwardly that strings (str objects) and bytes objects are supported. - Rewrite an example that relies on the int/float/complex special case. The example was correct but I think it's confusing to readers if we have examples unnecessarily rely on the special case. Instead, use example types with more straightforward behavior.
erictraut
reviewed
May 24, 2025
docs/spec/literal.rst
Outdated
| 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"] |
There was a problem hiding this comment.
Recommend deleting "Exactly" here. Including it might be confusing. (I'm not sure how equivalency could be inexact. :) )
There was a problem hiding this comment.
I did this for consistency with a few lines up, but I'll remove it there too.
docs/spec/literal.rst
Outdated
| @@ -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, | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Done. Also ended up making the enum example more explicit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Python 2. Instead, say straightforwardly that strings (str objects) and
bytes objects are supported.
The example was correct but I think it's confusing to readers if we have
examples unnecessarily rely on the special case. Instead, use example
types with more straightforward behavior.