I guess Carl's messages put an end to this proposal as it is. >From "the language side", I can think of nothing short of actually transforming _in place_ (like it is possible with instances of ordinary classes when you assign then a new "__class__") the "forward referenced object" into the complete classes.
This is not "unfeasable", but would be hackish as never before done, and there are practical problems: the final size of the class object itself cannot be known before the final committing of the class-body namespace into the final-namespace (slots, and inheritance of built-in classes with different layouts, etc...) Then, it looks like it only would be remotely practical for a static type checker if the class continuation is on the same file as its header. (I think I did not even consider they being in separate files - of course the name-rebinding would not work in that case) On the other hand, if it is practical to declare as header the complete interface of a class, with the intent of putting the actual methods with code later on, that is already possible, with typing.protocols ; whoever would take the time to split a class in two due to annotations, forward referencing, interface declaration separated from implementation, can just as well declare a protocol, as it exists today, I am not sure if typing.Protocol works nicely with inheritance, in the sense that it could inherit from other protocols or concrete classes, and present everything inherited as part of its interface, if it does not, then _that_ is the improvement needed so that what this proto-pep would allow could be done with them. best regards, js -><- On Sun, Apr 24, 2022 at 1:33 PM Carl Meyer <c...@oddbird.net> wrote: > On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno <gwid...@gmail.com> > wrote: > > > > I am not worried about the bikeshed part of which syntax to use - > > and more worried with the possible breaking of a lot of stuff, unless > > we work with creation of a non-identical "forward object" that is > > rebound, as in plain name binding, when the second part > > is declared. I've stated that amidst my ramblings, > > but Nick Coghlan managed to keep it suscint at > > > https://mail.python.org/archives/list/python-dev@python.org/message/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/ > > I don't think name rebinding works. That means that if we have > `forward class Bar` in module `foo` and `continue class Bar: ...` in > module `foo.impl`, if module `baz` does `from foo import Bar`, it will > forever have either the forward reference object or the real class, > and which one it has is entirely unpredictable (depends on import > ordering accidents of the rest of the codebase.) If `baz` happens to > be imported before `foo.impl`, the name `Bar` in the `baz` namespace > will never be resolved to the real class, and isn't resolvable to the > real class without some outside intervention. > > > """ > > 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. > > """ > > I'm not sure how this `resolve()` method is even possible under the > proposed syntax. If `forward class Bar` and `continue class Bar` are > in different modules, then how can `forward class Bar` (which must > create the "forward reference" object) possibly know which module > `continue class Bar: ...` exists in? How can it know how to resolve > itself? > > Carl >
_______________________________________________ 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/US6OOS7OJMEZKQQC456LDRQKC2HRP72P/ Code of Conduct: http://python.org/psf/codeofconduct/
