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/
"""
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.
"""
For that matter, syntax wise, it could just be:
break class XX()
...
continue class XX:
...
It gains at once no backwards incompatibility, and reuse concepts that
are already somewhat "grouped together".
On Sun, Apr 24, 2022 at 11:25 AM Eric V. Smith <e...@trueblade.com> wrote:
> On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote:
> > What's the use case for arbitrary expressions vs. a (possibly
> > qualified) name? A class factory that produces forward declarations?
> > Do you have a use case in mind?
>
> It's:
>
> x.py:
>
> ------8<--------
> forward class A()
> ------8<--------
>
> x_impl.py
>
> ------8<--------
> import X
>
> continue class X.A:
> # class body here
> ------8<--------
>
> It needs to be an expression because it's not defining a name, it
> referring to an existing name. You could use "from X import A" here and
> avoid a dotted expression, but it still needs to be an expression
> referring to an existing "forward class". Even if you restrict it to not
> having dots, it's logically an expression, not a name binding.
>
> Eric
>
>
> _______________________________________________
> 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/VV53MWDTYQCHBCAQGXLZ4SFCKUEHPQ2K/
> 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/WBXIZLNKWTJGAQLTFJOOPFJ7VCD42U6D/
Code of Conduct: http://python.org/psf/codeofconduct/
