[Python-Dev] PEP 359: The "make" Statement

Ian Bicking ianb at colorstudy.com
Tue Apr 18 01:44:38 CEST 2006


Steven Bethard wrote:
> This PEP proposes a generalization of the class-declaration syntax,
> the ``make`` statement.  The proposed syntax and semantics parallel
> the syntax for class definition, and so::
> 
>    make <callable> <name> <tuple>:
>        <block>

I can't really see any use case for <tuple>.  In particular, you could 
always choose to implement this:

   make Foo someobj(stuff): ...

like:

   make Foo(stuff) someobj: ...

I don't think I'd naturally use the tuple position for anything, and so 
it's an arbitrary and usually empty position in the call, just to 
support type() which already has its own syntax.

So maybe it makes less sense to copy the class/metaclass arguments so 
closely, and so moving to this might feel a bit better:

   make someobj Foo(stuff): ...

And actually it reminds me more of class statements, which are in the 
form "keyword name(things_you_build_from)".  Which then obviously leads 
to more parenthesis:

   make someobj(Foo(stuff)): ...

Except I don't know what "make someobj(A, B)" would mean, so maybe the 
parenthesis are uncalled for.  I prefer the look of the statement 
without parenthesis anyway.

Really, to me this syntax feels like support for a more prototype-based 
construct.  And many of the class-abusing metaclasses I've used have 
really looked similar to prototypes.  The "class" statement is caught up 
in a bunch of very class-like semantics, and a more explicit/manual 
technique of creating objects opens up lots of potential.

With that in mind, I think __call__ might be the wrong method to call on 
the builder.  For instance, if you were actually going to implement 
prototypes on this, you wouldn't want to steal all uses of __call__ just 
for the cloning machinery.  So __make__ would be nicer.  Personally this 
would also let people using older constructs (like a plain 
__call__(**kw)) to keep that in addition to supporting this new construct.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Python-Dev mailing list