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

Support PEP 675 (LiteralString) #12554

Open
JelleZijlstra opened this issue Apr 9, 2022 · 5 comments
Open

Support PEP 675 (LiteralString) #12554

JelleZijlstra opened this issue Apr 9, 2022 · 5 comments
Labels
affects-typeshed Anything that blocks a typeshed change feature meta Issues tracking a broad area of work topic-literalstring PEP 675

Comments

@JelleZijlstra
Copy link
Member

We should support LiteralString from PEP 675 (https://peps.python.org/pep-0675/).

As a first step, I would suggest changing the semantic analyzer to treat LiteralString simply as an alias for str. That's not correct, but it will be enough to enable third-party libraries and typeshed to start using LiteralString.

@JelleZijlstra JelleZijlstra added feature affects-typeshed Anything that blocks a typeshed change topic-literalstring PEP 675 labels Apr 9, 2022
@hmc-cs-mdrissi
Copy link
Contributor

hmc-cs-mdrissi commented Apr 10, 2022

Hmm, an alternative idea would be if typing_extensions/typing had feature flags like,

typing.PEP_675_SUPPORTED then typeshed could add to typing_extensions.pyi,

if not typing.PEP_675_SUPPORTED:
  LiteralString = str
else:
  LiteralString: _SpecialForm

and each type checker would have a list of recognized typing feature flags. For this specific case my hopeful guess is work involved isn't large but main reason I'd be interested in this is to make it possible to have stuff like,

if typing.PEP_646_SUPPORTED:
  def foo(...):
    ...
else:
  def foo(...):
    ...

where I'm guessing even basic support will be harder.

I'm assuming most feature flags would correspond to one typing pep.

@AlexWaygood AlexWaygood added the meta Issues tracking a broad area of work label Apr 10, 2022
@AlexWaygood
Copy link
Member

@hmc-cs-mdrissi, that might be nice, but we'd require agreement from all major type checkers to do something like that (such proposals should be discussed in the https://github.com/python/typing issue tracker rather than this one). For now, @JelleZijlstra's suggestion is probably easier.

hauntsaninja pushed a commit to hauntsaninja/mypy that referenced this issue Apr 11, 2022
JukkaL pushed a commit that referenced this issue Apr 13, 2022
Linking #12554

Co-authored-by: hauntsaninja <>
@dvarrazzo
Copy link

Hello,

just to let you know, I have introduced LiteralString in psycopg 3.1 codebase and I have used pyre as a one-off tool to identify and fix internal usage of non-literal strings (psycopg/psycopg#323). Of course the real deal will be for people using mypy to verify that their queries used with psycopg are safe.

I would like to throw at you an use case we could be interested in: to use mypy as a library to verify at import time or runtime that the user is not doing anything untoward. If you think that something of that sort might happen, please keep us informed.

Thank you!

@hauntsaninja
Copy link
Collaborator

Note that mypy has currently reverted python/typeshed#7725 in its vendored copy of typeshed (#13093, #13091) in order to avoid some inference regressions (#12982 (comment)). This is fine because mypy currently does not actually support LiteralString.

@FinchPowers
Copy link

Good day!

I'm wondering if there is an update regarding the inclusion of LiteralString in mypy?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-typeshed Anything that blocks a typeshed change feature meta Issues tracking a broad area of work topic-literalstring PEP 675
Projects
None yet
Development

No branches or pull requests

6 participants