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

[Steven Bethard]

On 4/17/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 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>.

FWIW, I've been thinking of the tuple as the "*args" and the block as
the "**kwargs".  But certainly any function can be written to take all
keyword arguments.

> In particular, you could always choose to implement this:
>
>    make Foo someobj(stuff): ...
>
> like:
>
>    make Foo(stuff) someobj: ...
[snip]
> and so moving to this might feel a bit better:
>
>    make someobj Foo(stuff): ...

Just to clarify, you mean translating:

  make <name> <callable>:
      <block>

into the assignment::

  <name> = <callable>("<name>", <namespace>)

?  Looks okay to me.  I'm only hesitant because on c.l.py I got a
pretty strong push for maintaining compatiblity with the class
statement.

> 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.

Yeah, I guess the real question here is, do we expect that types will
want to support both normal creation and creation using the make
statement?  If the answer is yes, then we definitely need to introduce
a __make__ slot.

Steve
--
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy