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 <carl@oddbird.net> wrote:
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno <gwidion@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