Since we are currently talking about the future of typeshed, there is another idea that's been floating around, and which was somewhat discussed in the past. In an ideal world, packages would maintain and ship their own type stubs (using the py.typed marker). At the moment is not realistic at all. I would categorize package projects into three groups: * Projects that already ship their own type stubs and have the knowledge to do so. Perfect. * Projects that are not interested in type stubs and have no interest in maintaining them. This is fine and their stubs can be maintained and distributed with typeshed. * Projects that are interested in shipping their own stubs, but are lacking the knowledge or tools to do so. The third group is what this idea is aimed at: I'd like to provide some kind of "Type School", where interested maintainers can ask for reviews of the stubs they want to add to their own project by typeshed maintainers or other interested and skilled parties. This way, we could nudge projects towards the first group and at the same time increase the user experience for end users, by not needing to install a type package. The easiest way to implement this is probably to add a issue template to typeshed for exactly that purpose. People could then review the linked PR and close the issue in typeshed. More sophisticated solutions are also possible, of course. I wonder what other people think about this. - Sebastian
I’d be happy to be a reviewer. I think this would be a huge help in moving typing forward. Why not have its own issue tracker, though? Brandt
On Oct 29, 2019, at 12:53, Sebastian Rittau <srittau@rittau.biz> wrote:
Since we are currently talking about the future of typeshed, there is another idea that's been floating around, and which was somewhat discussed in the past. In an ideal world, packages would maintain and ship their own type stubs (using the py.typed marker). At the moment is not realistic at all. I would categorize package projects into three groups:
Projects that already ship their own type stubs and have the knowledge to do so. Perfect. Projects that are not interested in type stubs and have no interest in maintaining them. This is fine and their stubs can be maintained and distributed with typeshed. Projects that are interested in shipping their own stubs, but are lacking the knowledge or tools to do so. The third group is what this idea is aimed at: I'd like to provide some kind of "Type School", where interested maintainers can ask for reviews of the stubs they want to add to their own project by typeshed maintainers or other interested and skilled parties. This way, we could nudge projects towards the first group and at the same time increase the user experience for end users, by not needing to install a type package.
The easiest way to implement this is probably to add a issue template to typeshed for exactly that purpose. People could then review the linked PR and close the issue in typeshed. More sophisticated solutions are also possible, of course.
I wonder what other people think about this.
- Sebastian
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Am 29.10.19 um 20:57 schrieb Brandt Bucher:
I’d be happy to be a reviewer. I think this would be a huge help in moving typing forward.
Why not have its own issue tracker, though?
Pros for own repo: * Overall more flexibility * Documentation (README) could be tailored to the school * We could add code samples (for example for CI integration) that are easier to find Pros for using typeshed: * Everything stub related in one repo * Existing infrastructure, maintainers, and contributors * Existing project under the python organization that has at least some visibility Overall I think a separate project has the edge, but starting on typeshed would be easier. - Sebastian
I'm in favor of starting this in its own repo, for the reasons Sebastian mentioned above. If that poses challenges with infrastructure/maintenance/contributors, I'd be happy to help out... actually, I'd be happy to help out anyways ;). How difficult is it to get a new repo for something like this under the Python organization? Brandt On Wed, Oct 30, 2019 at 2:40 AM Sebastian Rittau <srittau@rittau.biz> wrote:
Am 29.10.19 um 20:57 schrieb Brandt Bucher:
I’d be happy to be a reviewer. I think this would be a huge help in moving typing forward.
Why not have its own issue tracker, though?
Pros for own repo:
- Overall more flexibility - Documentation (README) could be tailored to the school - We could add code samples (for example for CI integration) that are easier to find
Pros for using typeshed:
- Everything stub related in one repo - Existing infrastructure, maintainers, and contributors - Existing project under the python organization that has at least some visibility
Overall I think a separate project has the edge, but starting on typeshed would be easier.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Get it under python/ might be a little messy. Getting it under psf/ would be easier.
El mar., 29 oct. 2019 a las 12:53, Sebastian Rittau (<srittau@rittau.biz>) escribió:
Since we are currently talking about the future of typeshed, there is another idea that's been floating around, and which was somewhat discussed in the past. In an ideal world, packages would maintain and ship their own type stubs (using the py.typed marker). At the moment is not realistic at all. I would categorize package projects into three groups:
- Projects that already ship their own type stubs and have the knowledge to do so. Perfect. - Projects that are not interested in type stubs and have no interest in maintaining them. This is fine and their stubs can be maintained and distributed with typeshed. - Projects that are interested in shipping their own stubs, but are lacking the knowledge or tools to do so.
The third group is what this idea is aimed at: I'd like to provide some kind of "Type School", where interested maintainers can ask for reviews of the stubs they want to add to their own project by typeshed maintainers or other interested and skilled parties. This way, we could nudge projects towards the first group and at the same time increase the user experience for end users, by not needing to install a type package.
The easiest way to implement this is probably to add a issue template to typeshed for exactly that purpose. People could then review the linked PR and close the issue in typeshed. More sophisticated solutions are also possible, of course.
I wonder what other people think about this.
It's great to try out new ideas like this one, and I'm supportive of trying it out. We should see how many package maintainers are interested in doing this.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
On Tue, 29 Oct 2019 at 19:53, Sebastian Rittau <srittau@rittau.biz> wrote:
Since we are currently talking about the future of typeshed, there is another idea that's been floating around, and which was somewhat discussed in the past. In an ideal world, packages would maintain and ship their own type stubs (using the py.typed marker). At the moment is not realistic at all. I would categorize package projects into three groups:
- Projects that already ship their own type stubs and have the knowledge to do so. Perfect. - Projects that are not interested in type stubs and have no interest in maintaining them. This is fine and their stubs can be maintained and distributed with typeshed. - Projects that are interested in shipping their own stubs, but are lacking the knowledge or tools to do so.
The third group is what this idea is aimed at: I'd like to provide some kind of "Type School", where interested maintainers can ask for reviews of the stubs they want to add to their own project by typeshed maintainers or other interested and skilled parties. This way, we could nudge projects towards the first group and at the same time increase the user experience for end users, by not needing to install a type package.
The easiest way to implement this is probably to add a issue template to typeshed for exactly that purpose. People could then review the linked PR and close the issue in typeshed. More sophisticated solutions are also possible, of course.
I wonder what other people think about this.
I think this is a great idea! I think this may be also useful for people who are excited about static typing in Python, but have little experience with modern statically typed languages. I think we would also need to somehow advertise this. Probably we can add links on mypy landing page, and in the docs. -- Ivan
participants (5)
-
Brandt Bucher -
Brett Cannon -
Ivan Levkivskyi -
Jelle Zijlstra -
Sebastian Rittau