Skip to content
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

Add docs for Literal types #6150

Merged
merged 5 commits into from
Jan 10, 2019
Merged

Conversation

Michael0x2a
Copy link
Collaborator

This pull request adds some documentation on using Literal types.

It focuses mostly on how they can be parameterized, and different ways of declaring variables to be Literal.

These docs deliberately do not mention the "intelligent indexing" feature: we don't yet support intelligently indexing using variables that are declared to be Final, so I think we should leave this feature undocumented for now.

(I'll add in that feature + update the docs once #6081 lands.)

This pull request adds some documentation on using Literal types.

It focuses mostly on how they can be parameterized, and different
ways of declaring variables to be Literal.

These docs deliberately do not mention the "intelligent indexing"
feature: we don't yet support intelligently indexing using variables
that are declared to be Final, so I think we should leave this
feature undocumented for now.
@Michael0x2a
Copy link
Collaborator Author

Also, we should probably delay merging this PR until we've released a new version of typing_extensions to pypi.

docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
@Michael0x2a
Copy link
Collaborator Author

@bluetech -- Thanks! I made all of the changes you suggested.

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

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

Thanks for writing the docs! I have many stylistic suggestions, but otherwise I am happy with this PR (you can merge after addressing them).


Literal is an officially supported feature, but is highly experimental
and should be considered to be in alpha stage. It is very likely that future
releases of mypy will modify the behavior of Literal types, either by adding
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
releases of mypy will modify the behavior of Literal types, either by adding
releases of mypy will modify the behavior of literal types, either by adding

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Just to double-check, did you want me to lowercase every instance where I use "Literal" as a proper noun?

I capitalized this (and every other time I used the phrase "Literal types") because I wanted to refer specifically to the Literal[...] type itself. I can lowercase this if there's a good reason for it, but then we should probably lowercase that phrase every other time I use it.

Copy link
Member

Choose a reason for hiding this comment

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

Ideally I would prefer to always use one of two: literal or ``Literal`` (i.e. if it is capitalized, then it is ``code``).

docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
reveal_type(b) # Revealed type is 'int'

If you find repeating the value of the variable in the type hint to be tedious,
you can instead declare the variable to be :ref:`Final <final_attrs>`:
Copy link
Member

Choose a reason for hiding this comment

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

"Final variable" is an kind of oxymoron. I would rather say "final name", or reformulate this otherwise.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I decided to rephrase this to say "you can instead change the variable to be Final" (and did a similar thing below).

docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
docs/source/more_types.rst Outdated Show resolved Hide resolved
@JukkaL
Copy link
Collaborator

JukkaL commented Jan 7, 2019

Can you create a new top-level file for literal types? more_types.rst is kind of long, and I'd like to split it up at some point.

@Michael0x2a
Copy link
Collaborator Author

@JukkaL and @ilevkivskyi -- FYI: I made the last few changes you suggested! (I moved the doc to the top level and changed the capitalization).

@Michael0x2a Michael0x2a merged commit bc6308b into python:master Jan 10, 2019
@Michael0x2a Michael0x2a deleted the add-docs-for-literal branch January 10, 2019 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants