I should have said "numpy_forward", not "numpy.forward". I changed my mind at the last second as I was writing that email, and momentarily forgot that when you import x.y you implicitly import x.
/arry On Sat, Apr 23, 2022, 01:53 Larry Hastings <la...@hastings.org> wrote: > > On 4/23/22 01:14, Steven D'Aprano wrote: > > 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* >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QHHI3D2T7MK2Y4SCRJ33BO433R4MKZYU/ Code of Conduct: http://python.org/psf/codeofconduct/
