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.
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.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
