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/
