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? I might have missed it, but I don't think I've seen this discussed on the typing-sig mailing list. Or have I misunderstood? If typing is not driving this, what is? > >One other edge case here is how would you forward declare an annotation > >for a type that like this, > > > >if TYPE_CHECKING: > > import numpy > > > >def f(x: numpy.ndarray) -> None: > > ... > > > >forward declaring ndarray here would not make numpy.ndarray available. > > In this case, adding forward declarations for classes in "numpy" would > be up to the "numpy" module. One approach might look more like this: > > import numpy # contains forward declarations > if TYPE_CHECKING: > import numpy.impl 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. from numpy import ndarry a = ndarray([1, 2]) # Fails, because its a FDCO import some_random_module # which happens to import numpy.impl # which finishes the initialisation of the class object a = ndarray([1, 2]) # and this now magically works! -- Steve _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5NPG3AG2GYDY7S3RBZD3XTUQDD7WQEQU/ Code of Conduct: http://python.org/psf/codeofconduct/