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? 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/
