PEP 359: The "make" Statement

[Tim Hochberg]

Carl Banks wrote:
> Mike Orr wrote:
> 
>>>I think this PEP is going off the rails. It's primary virtue was that it
>>
>>was a simpler, clearer way to write:
>>
>>     class Foo(args):
>>        __metaclass__ = some_metaclass
>>        #...
>>
>>And it doesn't even do that.  What's wrong with "class Foo:
>>__metaclass__ = blah"?  Two lines of code, and the double underscores
>>indicate something special is happening.
> 
> 
> I think you're missing the point somewhat.  The real point isn't to
> make using metaclasses easier; it's to let the useful semantics of the
> class statement be used for things that aren't classes.

I can see how you might get the impression from the above paragraph, but 
you'd be wrong.


> 
> Example: I can define the following "metaclass":
> 
> def PropertyMaker(name,bases,pdict):
>     fget = pdict.get("get",None)
>     fset = pdict.get("set",None)
>     fdel = pdict.get("delete",None)
>     doc = pdict.get("__doc__",None)
>     return property(fget,fset,fdel,doc)
> 
> Then, I could define a property inside some class definition like this:
> 
> class some_attribute:
>     __metaclass__ = PropertyMaker
>     def get(self):
>         whatever
>     def set(self,value):
>         whatever
> 
> But the thing is, if I did that, I'd be lying bastard.  I'd be using
> the class statement and the __metaclass__ property; however, the object
> I'm creating is not a class (it's a property), and the thing I'm
> assigning to __metaclass__ is not a metaclass (it's a factory
> function).  With the make statement, I could instead write:
> 
> make property some_attribute:
>     def get(self):
>     # etc.
> 
> Then I'm not lying about it, and I'm using a more straightforward
> syntax.
> 
> If this proposal were just about metaclasses, I agree that wouldn't be
> important enough to justify a new statement.  Metaclasses aren't too
> common, and are generally used by experts who don't need the
> straightforwardness the make statement would provide.
> 
> But, properties, dicts, and other things could benefit from some of the
> semantics the class statement, and with the make statement, the average
> user could take advantage of that without having to worry about all
> this circumlocative metaclass hackiness.

Here you've missed the point of my post. The post itself was not all 
that clear, I admit, but had you read the subsequent followups, it would 
have been clear that I wasn't arguing against the utility of the 
statement (nor was I arguing for it), I was arguing against complicating 
it for a useless use case. In particular making the namespace associated 
with make statement into some sort of quasi namespace in order to 
support the generating of HTML seems foolish for two reasons. First, it 
doesn't actually work in any but the most trivial of cases. Second, 
there is an existing syntax (as of 2.5) that can fill the same roll, 
only it actually works, specifically the 'with' statement.

Regards,

-tim