I think we should seriously consider having a build system that generates the actual NumPy stubs. @eric-wieser suggested that for platform-specific types (e.g. np.intp) we:

As part of setup.py, we could import numpy and generate the alias stubs based on the actual alias values

which seems like a nice and clean solution (especially for types like np.float96 which may or may not exist depending on the platform). Adding some kind of "stub-generation" step would also let us reduce a lot of boilerplate that we'd have to do otherwise:

• All distribution generators in numpy.random should have the same type signatures as numpy.random.RandomState (so they need to be copy-pasted and kept in sync)
• The interactions between arrays and scalars and broadcasting sometimes require a lot of repetitive @overload functions (see the distributions in [WIP] Typehint np.random numpy-stubs#11 as an example).

This would also give us a chance to enforce some lints of our own, like:

• The various *Like types should only ever be taken as function input types and never as return types.

Of course, there are also downsides with having a stub-generation step:

• Generating valid Python stubs can be tricky (due to significant whitespace) and there don't seem to be standard solutions to do this (AFAIK).
• This adds more complexity to the project -- instead of being able to just read the stubs and make changes to fix bugs people will have to understand whatever generator framework we use and debug that too
• If we run the stub generation when a user installs stubs, then whatever dependencies we use for framework generation will have to be pre-installed or vendored

I think that the added complexity would be worth it, but I'm curious what everyone else's opinions are.

cc @shoyer @eric-wieser