Drop .pyi?
#1993
Replies: 1 comment
-
An advantage of having separate pyi files, aside from the ability to quickly scan interfaces without needing an external tool (in theory the stubs could even have the docstrings though I think that would cause Sphinx some issues) is that they have a non-insignificant runtime cost (during import). PEP 563 / 649 (deferral of annotations evaluation to mitigate this) was originally slated to become the default behaviour in 3.10, but turns out to break the world, so for now it's been postponed to 3.11, conditional of finding solutions for existing users: https://mail.python.org/archives/list/[email protected]/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Any opinions on dropping the
.pyi
definitions? I'd need to do a bit more research to be sure, but maybe they're no longer needed if we can roll the hints directly into the Python?I could spend a little time on further research + a PR for this if there's no opposition.
(The itch I'm trying to scratch is that they're already out of sync with the Python, so my IDE complains, needlessly, which technically could just be a PyCharm problem, but I think the way forward is direct. e.g.
ProjectCard.move(…)
is missing from the type def.)Beta Was this translation helpful? Give feedback.
All reactions