-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
typeshed types module #4131
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
Comments
This sounds like a useful thing to have. What about adding an underscore prefix to make it clear that this is an internal module? |
An underscore makes sense. |
I don't understand why it should be an internal module. If the types are only for use in typeshed, that weakens @srittau's idea in python/typing#728: "then possibly transferring them to typing if they prove to be used". The community would benefit more from these types if they were not limited for use inside typeshed, and it would be easier to ascertain which should graduate to the standard library. Popularity inside typeshed is very different from popularity among the wider Python community. |
The types can be used outside typeshed, but we give no API guarantees, and due to the nature of typeshed, it won't be available at runtime. I think marking it with an underscore to point out that special nature makes sense. |
Having the types only live in typeshed simplifies workflows, as we can add a new type without having to release a package on PyPI. If the types were public, we'd need to think much more carefully about which types are worth adding, how they should be named, etc. We would effectively be blocked from making backwards incompatible changes, as third-party code might depend on the types. Since protocol types and type aliases use structural compatibility, nothing prevents maintaining a completely separate package on PyPI (with stubs in typeshed) that contain various protocols and type aliases that could be generally useful. |
This PR only replaces a few potential places where this alias could be used. Closes: python#4131
This came up before. I suggest to add a typeshed-only module what contains type aliases and protocols useful for the stdlib, but not part of typing.py. We already have a
wsgiref.types
module with such functionality and #3371 will addio._OpenBinaryMode
andio._OpenTextMode
. Another common type we need are I/O protocols.Such a module could also act as a staging and testing area for types that are generally useful and could eventually migrate over to
typing.py
(viatyping_extensions.py
).As a name I suggest
stdlib/2and3/typeshed.pyi
.The text was updated successfully, but these errors were encountered: