Jukka Lehtosalo wrote:
> On Tue, Oct 22, 2019 at 9:59 AM Ivan Levkivskyi levkivskyi@gmail.com
> wrote:
> > Also IIUC Jukka (cc'ed) is going to spend a week or
> > two early November
> > working 100% on kick-starting
> > the transformation of typeshed to a more modular model.
That's great to hear! Is any of this outlined/planned somewhere? Or is this all in your head, Jukka? ;)
I wrote something about this during PyCon, but I've lost track of my notes. I'll try to find them :-)
That would be great! I can't promise anything, but if there's a plan I can at least point people at that plan if they are motivated enough to help out.
Yeah, when I thought about the dream scenario the one that came to mind would be to check projects for `py.typed` and if they lacked it and a `-stubs` project to then generate the stubs for the project as best effort. And then if someone came along and contributed a better, tighter set of stubs to then test that they would be valid to the best of everyone's knowledge somehow in an automated fashion. That way short of needing to step in for spam purposes, things could more-or-less be optimized.
I'd love if contributing auto-generated stubs to typeshed would be a very low-friction process. If we manage to do this, it should be quite feasible to have, say, hundreds of additional packages supported without a lot of effort.
Well, in my dream it's **all** of PyPI, so a bit more than triple digits. :)
And once we have baseline stubs, I hope that we'll soon have many new contributors to gradually improve the annotation coverage of the stubs. In my experience getting started with a new set of stubs is the hard part, and incremental change is quite easy afterwards.
Yeah, that would be my hope.
One thing I have always wondered about is how typeshed handles package versions? It's currently a completely flat namespace with no inherent versioning, so when a major version for a package comes out that changes the types of things in a non-backwards-compatible fashion, how are projects supposed to express that for type stubs on typeshed (or in their `-stubs` packages on PyPI for that matter)?
Currently there is no story for versioning, but for the modular typeshed idea we'd probably at least want to add some metadata about package versions. I think that there was some discussion about this some time ago, but I can't remember where.
I guess it's more of a question of what's the overhead of pulling forward stubs when there is little to no change versus wider coverage. As Jelle said, there's probably minimal shift for the large, old projects that have type stubs on typeshed. But when I'm think of what it would take to type all of PyPI then that no longer holds. :)
It seems like project version support is really critical if you go down the automation route to provide baseline support, and then you can rely on testing to either carry forward any handwritten types and then fall back to new auto-generated versions when things would break by blindly pulling something forward.