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

typeshed types module #4131

Closed
srittau opened this issue May 28, 2020 · 6 comments · Fixed by #4161
Closed

typeshed types module #4131

srittau opened this issue May 28, 2020 · 6 comments · Fixed by #4161
Labels
project: policy Organization of the typeshed project

Comments

@srittau
Copy link
Collaborator

srittau commented May 28, 2020

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 add io._OpenBinaryMode and io._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 (via typing_extensions.py).

As a name I suggest stdlib/2and3/typeshed.pyi.

@srittau srittau added the project: policy Organization of the typeshed project label May 28, 2020
@srittau
Copy link
Collaborator Author

srittau commented May 28, 2020

Another example is _FormatMapMapping from #3824 and a general "mapping" protocol (see also #3576).

@JukkaL
Copy link
Contributor

JukkaL commented May 28, 2020

This sounds like a useful thing to have. What about adding an underscore prefix to make it clear that this is an internal module?

@srittau
Copy link
Collaborator Author

srittau commented May 28, 2020

An underscore makes sense.

@ramalho
Copy link
Contributor

ramalho commented May 29, 2020

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.

@srittau
Copy link
Collaborator Author

srittau commented May 29, 2020

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.

@JukkaL
Copy link
Contributor

JukkaL commented May 29, 2020

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.

srittau added a commit to srittau/typeshed that referenced this issue Jun 3, 2020
This PR only replaces a few potential places where this alias could be
used.

Closes: python#4131
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

Successfully merging a pull request may close this issue.

3 participants