Proto-PEP part 3: Closing thoughts on "forward class", etc.
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/
On Sat, 23 Apr 2022, 11:17 am Larry Hastings, <larry@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-leave@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/HD7YPONS... Code of Conduct: http://python.org/psf/codeofconduct/
participants (2)
-
Larry Hastings -
Nick Coghlan