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

Literal support for typeshed #2913

Closed
2 of 4 tasks
srittau opened this issue Apr 12, 2019 · 9 comments
Closed
2 of 4 tasks

Literal support for typeshed #2913

srittau opened this issue Apr 12, 2019 · 9 comments
Labels
project: policy Organization of the typeshed project

Comments

@srittau
Copy link
Collaborator

srittau commented Apr 12, 2019

This has come up a few times now. When/how do we want to support literals? To make an informed decision, we should know which of our important users already support literals or plan to support them with the next version.

@gvanrossum
Copy link
Member

It would probably help if PEP 586 was accepted. :-)

That's waiting for me to petition the Python Steering Council to make me the BDFL-Delegate and then for me to review it. I'm behind on PEP reviews, and it's a long PEP, and IIRC @Michael0x2a is still hoping to finesse the draft. (And the implementation, e.g. he's working on support for enums.) And we should have some public discussion on typing-sig@python.org. But I have no doubt that it will be accepted more or less as it currently stands.

In the meantime is there a way to write

foo = Literal[42]

so that in type checkers other than mypy, it comes down to foo = Any?

@ilevkivskyi
Copy link
Member

Maybe we should standardize something like

if MYPY:
    foo = Literal[42]

and similar for other type checkers, i.e. if PYTYPE: ..., if PYRE: ... etc.? I think this was proposed at some point but I can't find the discussion.

@gvanrossum
Copy link
Member

But how would the other checkers know to ignore code inside if MYPY? E.g. mypy doesn't currently ignore code inside if False.

@ilevkivskyi
Copy link
Member

I am not sure, there are several options. For example, we can define a special constant TYPE_CHECKER = False, so that aliases like PYRE = TYPE_CHECKER would be treated as always false (i.e. not type checked), except for the constant whose name matches the type checker.

@ilevkivskyi
Copy link
Member

This way people can probably even try to simplify migration between type checkers, or use multiple type checkers if they disagree on some details.

@rchen152
Copy link
Collaborator

For pytype, mapping Literal to Any would be straightforward: we already have a directory of pytype-specific type stubs that shadow the typeshed ones (https://github.com/google/pytype/tree/master/pytype/pytd/builtins), so we'd just need to add Literal = Any to a typing_extensions stub there (and eventually to typing if we still don't support Literal when it migrates over).

My concern about if MYPY, if PYTYPE, etc., is that when I look at the version and platform checks that already exist, they add a fair bit of complexity to the stubs, and I'd be hesitant to introduce yet more.

@carljm
Copy link
Member

carljm commented Jun 14, 2019

Per recent thread on typing-sig, pytype doesn't yet support Literal but is OK with its use in stubs and won't error on it. Pyre and Mypy both support it. So I guess the only other blocker here is to make sure it won't cause problems for PyCharm? @vlasovskikh ?

@srittau
Copy link
Collaborator Author

srittau commented Jun 14, 2019

Literals are now accepted per discussion on typing-sig.

@srittau srittau closed this as completed Jun 14, 2019
@vlasovskikh
Copy link
Member

@carljm PyCharm will support Literal in future versions, it's OK to use them in Typeshed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project: policy Organization of the typeshed project
Projects
None yet
Development

No branches or pull requests

6 participants