On Sat, 23 Apr 2022, 11:17 am Larry Hastings, <la...@hastings.org> wrote:
> > > Just a quick note from me on the proto-PEP and the two proposed > implementations. When I started exploring this approach, I didn't suspect > it'd require such sweeping changes to be feasible. Specifically, I didn't > think I was going to propose changing the fundamental mechanism used to > create class objects. That's an enormous change, and it makes me > uncomfortable; I suspect I won't be alone in having that reaction. > > The alternate implementation with proxy objects was borne of my reaction, > but it's worrisome too. It's a hack--though whether it's a "big" hack or a > "small" hack is debatable. Anyway, I'm specifically worried about the > underlying class object escaping the proxy and becoming visible inside > Python somehow. If that happened, we'd have two objects representing the > same "type" at runtime, a situation that could quickly become confusing. > > Also, as I hopefully made clear in the "alternate implementation" approach > using a class proxy object, I'm not 100% certain that the proxy will work > in all cases. I ran out of time to investigate it more--I wanted to post > this idea with some lead time before the 2022 Language Summit, so that > folks had time to read and digest it and discuss it before the Summit. I > have some implementation ideas--the "class proxy" class may need its own > exotic metaclass. > > Ultimately I'm posting this proto-PEP to foster discussion. I'm confident > that "forward class" / "continue class" could solve all our > forward-reference and circular-reference problems; the questions we need to > collectively answer are: > > - how should the implementation work, and > - is the cost of the implementation worth it? > > Something worth considering: whether forward references need to be *transparent* at runtime. If they can just be regular ForwardRef objects then much of the runtime complexity will go away (at the cost of some potentially confusing identity check failures between forward references and the actual class objects). ForwardRef's constructor could also potentially be enhanced to accept a "resolve" callable, and a "resolve()" method added to its public API, although the extra complexity that would bring may not be worth it. Cheers, Nick. > > > Best wishes, > > > */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/HD7YPONSPL5ZFZISKCOUWVUXMIJTQG2M/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/ Code of Conduct: http://python.org/psf/codeofconduct/
