Larry Hastings writes:
 > On 4/22/22 19:36, Terry Reedy wrote:

 > > How about a 'regular' class statement with a special marker of some 
 > > sort.  Example: 'body=None'.
 > 
 > It's plausible.  I take it "body=None" would mean the declaration would 
 > not be permitted to have a colon and a class body.  So now we have two 
 > forms of the "class" statement, and which syntax you're using is 
 > controlled by a named parameter argument.
 > 
 > I think this "body=None" argument changing the syntax of the "class" 
 > statement is clumsy.

How about another predefined keyword in class definitions?

    class ForwardDeclared(*bases, metaclass=Meta, declaration=True):
        pass

AIUI, in your scheme you can't have a body in a forward declaration,
so in this one you could error on a non-pass body, or just ignore it.

I don't see how you can avoid the 'continue class' statement, if you
want the actual argument to be an arbitrary expression that evaluates
to an incomplete class.  Then the symmetry of the 'forward class'
statement is appealing.  If you restrict it to be a name, though, you
could use

    class SomeModule.ForwardDeclared(declaration=False):
        # body goes here

I think.

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?

I dunno, but all this seems really complicated, unless you go the
proxy object route (which is basically what we have now, except that
str is extremely limited as a proxy, you could call it a PINO :-).
Sure, there are risks if the temporary thing produced by forward
class' escapes, but if both the "thing" and the proxy are limited
enough, there will be little incentive to do that.  Consenting adults.
Just add the FAFO warning label.  Add features when they're called for.

A separate question:
There are going to be metaclasses that define __new__ whose instances
cannot be used in forward declarations because the class object can't
be created until the class body is seen, and therefore cannot be split
into __new_forward__ and __new_continue__, I suppose.  Is that true?

_______________________________________________
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/SQB63XJWE67NVOT4XT6I3RSU4HS73AGL/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to