Repository navigation
Missing quotations around forward references #3334
Description
I'm in progress updating the Microsoft language server's copy of the typeshed repo in preparation for 3.8, and some type annotations we had been testing have broken on moving up to the latest master of typeshed (microsoft/python-language-server#1654).
Specifically #3191 removed some quotations around forward references, which broke some testing we had done to verify handling of Path's division overloads.
As far as I can tell from PEP 484, forward references should be using strings for types rather than actually referencing them (https://www.python.org/dev/peps/pep-0484/#forward-references), and our type system needs this assumption to be able to evaluate things correctly. In our case, replacing:
_P = TypeVar('_P', bound=PurePath)with:
_P = TypeVar('_P', bound='PurePath')Means we can process the stub, and this seems more reasonable from the point of "executing" the stub (if stubs could be run as-is), since PurePath has not yet been defined.
Should these forward references have been unquoted? Or has there been some change to the spec that isn't documented in the PEP?
Activity
gvanrossum commentedon Oct 9, 2019
Actually there is a special exception for stub files -- forwards references in those do not have to be enclosed in quotes. Stubs are not meant to be executed, so the reason for the quotes is not there.
jakebailey commentedon Oct 9, 2019
Is there a listing of all of the differences that stub files may have from regular code that uses typing? I didn't see that stub files had an exception like this in the PEP 484 docs.
The
pathlibexample is tricky because the bound created for_Prefers back again to_P(so at least at the moment, I think we end up not having_Pdefined when it's needed later on). Likely fixable on our end, just tricky since we hadn't considered it.jakebailey commentedon Oct 9, 2019
I'll likely close this since I think that it's something for us to fix, but knowing where to find some info on the stub exceptions would be nice to have. 😃
JelleZijlstra commentedon Oct 9, 2019
We're (slowly) working on documenting this sort of thing at https://github.com/srittau/type-stub-pep.
jakebailey commentedon Oct 11, 2019
In the meantime, it'd be helpful for this repo's README to not state that stubs can be interpreted by Python 3 (https://github.com/python/typeshed#format), and perhaps point to the proposed new specs with a note that the stubs here aren't following PEP 484 exactly. The way stubs are structured differing from typical Python is a bit of a bummer for analyzers which relied on that being the case and were just following what was written in PEP 484. 🙁
superbobry commentedon Sep 30, 2020
Hi @JelleZijlstra, out of curiosity has there been any progress on the type stubs PEP since?
srittau commentedon Oct 1, 2020
It's still on my agenda, but nothing new so far.