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

Phillip J. Eby pje at telecommunity.com
Thu Apr 13 23:04:22 CEST 2006


At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
>On 4/13/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
> > >Sorry, I'm not clear on exactly what you're suggesting.  Are you
> > >suggesting I try to implement the make-statement using context
> > >managers?  Or that I use a context manager to address Martin's
> > >problem?
> >
> > Yes.  :)  Both.  Or neither.  What I'm suggesting is that you implement the
> > *use cases* for the make statement using 'with' and a bit of getframe
> > hackery.  Then, your PEP can be clearer as to whether there's actually any
> > significant advantage to having a "make" statement.
> >
> > IOW, if "make" isn't anything more than yet another way to spell class
> > decorators, metaclasses, or "with" statements, it's probably not a good
> > idea to add it to the language.
>
>I'm against using anything with getframe hackery

That's irrelevant; the point is that your PEP should show why a statement 
is *better*, either by showing the hackery isn't possible, isn't practical, 
or at least is hacky.


>  but here are the use
>cases written with the class/__metaclass__ abuse:

How is it *abuse* to use a language feature as it's designed?


>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.  At the moment, 
that's not particularly clear from the PEP, which talks about generalizing 
the class declaration syntax -- something that's already sufficiently 
general, for classes.

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







More information about the Python-Dev mailing list