[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