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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com