Use stubgen to generate stubs for all standard library modules

[JukkaL]

Maybe we should run stubgen against all standard library modules and include the generated stubs in the repo with little or no manual review. Even if some of them might be of limited use, it's better to have some stubs for every module rather than only having manually vetted stubs for a subset of the modules.

Similarly, we could auto-generate stubs for the most widely used 3rd party modules. It would probably make sense to verify stubs for 3rd party modules more carefully as they may be more likely to do things that will confuse the stub generator -- but that's just a hunch.

It would then be easy for people to file issues against stubs that have issues and send pull requests that add type annotations to stubs.

[wizzardx]

I like that idea.

Can we keep using the current stubs (by default), but then use a command-line arg to use these newer stubs?

At the same time, bug reports / etc should be encouraged to go against the new stubs, rather than the old stubs.

Later on we can make the new stubs the default, but include a backwards-compat option to use the older stubs.

Might be useful to generalize that - eg selecting "generation 1" stubs, "generation 2" stubs, "generation 3" stubs, etc - where what we have now is gen 1, and gen2 is the one we want to start transitioning in to, and eg gen 3 would be some later generation of stubs that we want to transition over to.

[wizzardx]

Actually... wouldn't also work fine / transparently - if we used these new stubs (gen 2), but where present in the older stubs (gen 1) (on a per-declaration level - eg per function/class/etc) - we prefer the gen 1 version?

Then over time, gen1 can be phased out / have everything relevant migrated over.

Basically, pyi files that act as a bunch of patches on top of/inheriting from each other (on the declaration level), rather than eg - only one main pyi file per module.

[wizzardx]

Simple way to do this might be like this, eg in ipaddress module for instance:

from old_ipaddress import *

<new declarations here, replacing or adding on to stuff found in old_ipaddress>

[wizzardx]

Sorry, other way around.

gen1.ipaddress:

from gen2.iaddress import *

Basically, we're always using the oldest/current generation of stub files, but newer generations of stub file can automatically add in things (that aren't covered by the older stubs). And then gradually we can migrate stubs from older gen stubs back to newer gen stubs, until finally, we can remove the older gen pyi file, and the newer gen pyi file is all that gets used.

"import from *" wouldn't be the exact semantics - you'd also want to in this case import private module attributes. Maybe a "# mypy: inherit from module" pragma, or similar...

(apologies - I'm brainstorming a bit in this thread).

[o11c]

It's worth noting that stubgen will not always produce valid stubs.

For example, stubgen will happily emit references to base classes that were deleted from (or never existed in) the module.

[JukkaL]

The generated stubs wouldn't always be correct, but I've used stubgen quite a lot recently and it works pretty well. Slightly broken stubs are probably still better than no stubs. For existing, incomplete stubs, it may make sense to manually merge the autogenerated stubs with the existing stubs, at least for small stubs. But the low hanging fruit is to generate stubs for modules that have no stubs at all right now, and leave other stubs as they are.

Also, feel free to create issues for any stubgen limitations you encounter. They may be easy to fix.

[wizzardx]

That actually sounds pretty good.

I was reading that as we're going to be dropping support for the currently-vetted stub files, replacing them with auto-generated stubs, break a lot of things, and then start a large amount of editing to fix the auto-generated-stubs that cause problems where there weren't problems before we replaced them.

I'm also personally pretty fine with (manually) merging of current stubs into larger auto-generated versions of the same modules - there should be a lot less breakage that way.

[JukkaL]

Closing the issue as stubs are now maintained in typeshed.