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

Steven Bethard steven.bethard at gmail.com
Thu Apr 13 23:23:08 CEST 2006


On 4/13/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
[snip examples using class/__metaclass__ statements to create non-types]
> >The question is, is the intent still clear?
>
> Depends on your use case.  I'm just saying that the PEP would be tons
> clearer if it started out by saying right up front that its goal is to
> provide a prominent form of syntax sugar for __metaclass__ uses in cases
> where the thing being create isn't particularly class-like.

Good point.  I'll try to elaborate on that a bunch.

> The PEP also doesn't explain why, for example, it shouldn't simply allow
> 'callable' to be an arbitrary expression, invoked with
> 'callable(name,namespace)'.  I'd presume this is to allow backward
> compatibility with metaclasses...  except the statement is for making
> things that *aren't* classes, so why is compatibility needed?
>
> The PEP also doesn't explain why the particular syntax order is
> chosen.  Why is it "make callable name(tuple):" and not, say, "make
> name(tuple) from callable:" or "name = callable(tuple):" (which doesn't
> require a new keyword).

Thanks for the feedback.  I'll put that into the PEP too, but in short
the answer is that the particular syntax follows the class syntax
exactly except that "class" is replaced by "make <callable>".  There
have been a lot of other proposals that try to introduce dramatically
new syntax for these sorts of things, e.g. `Nick Coghlan's
suggestion`_ to allow ** to indicate that keyword arguments would be
supplied on the following block, e.g.::

    options = dict(**):
        def option1(*args, **kwds):
            # Do option 1
        def option2(*args, **kwds):
           # Do option 2

(Nick's doesn't solve the DRY issue when you need to know the name of
the thing being created, but I'll ignore that for the moment.)
Basically, I was trying to be as un-creative syntactically as
possible, hoping that Python programmers would be able to translate
their knowledge of how the class statement works into knowledge of how
the make statement works.

.. _Nick Coghlan's suggestion:
http://mail.python.org/pipermail/python-3000/2006-April/000689.html

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


More information about the Python-Dev mailing list