On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:

But rather than speculate further, perhaps someone who works on one of 
the static type analysis checkers will join the discussion and render an 
informed opinion about how easy or hard it would be to support "forward 
class" and "continue class".

No offense Larry, but since this proto-PEP is designed to help the 
typing community (I guess...) shouldn't you have done that before 
approaching Python-Dev with the proposal?

The perfect is the enemy of the good.  Like I said, I wanted to get this out there before the Language Summit, and I just ran out of time.  I think there's also some sort of typing summit next week?  I'm not really plugged in to the static type analysis world--I don't use it in any of my projects.

Wouldn't that be a massively breaking change? Anyone who does:

    from numpy import ndarray

will get the forward-declared class object instead of the fully 
initialised class object, leading to all sorts of action-at-a-distance 
bugs.

I wasn't recommending The Famous numpy Project do this exact thing, it was an abstract example using the name "numpy".  I didn't think this was a real example anyway, as I was assuming that most people who import numpy don't do so in an "if TYPE_CHECKING:" block.

Separating the forward class declaration from the continue class implementation in the actual "numpy" module itself is probably not in the cards for a while, if ever.  But perhaps numpy could do this:

import numpy.forward
if TYPE_CHECKING:
    import numpy

In this case, the "numpy" module would also internally "import numpy.forward", and would contain the "continue class" statements for the forward-declared classes in "numpy.forward".

There are lots of ways to solve problems with the flexibility afforded by the proposed "forward class" / "continue class" syntax.  Perhaps in the future you'll suggest some of them!

/arry