[Python-3000] PEP for Metaclasses in Python 3000

[Talin]

Greg Ewing wrote:
> Another thought: It's not strictly necessary to
> allow for arguments to the metaclass, since the same
> effect can be achieved with a factory function, like
> we do for decorators.

True. The main reason for doing it the way that I did, is to allow for 
the future possibility of the *default* metaclass interpreting some of 
those keywords.

I'll give you an example: Suppose the author of Pyrex realizes that 
there is a potential optimization available if classes can be declared 
'sealed', in other words the class author is telling the compiler that 
this class will never be used as a base class. This allows the dispatch 
table to be simplified considerably - in many cases, eliminating the 
need for a run-time dict lookup of the method. So in this case, the 
default metaclass might accept the keyword 'sealed' to indicate this fact.

Now, it's true that I don't know exactly what uses people will make of 
this keyword-argument facility, but I don't consider that alone to be a 
show-stopper. I agree that, in the general case, one shouldn't add 
features to a language for no reason. However, its often the case that 
when we add a new feature, such as generators, we don't really know all 
of the potential uses to which it will be put. And that's a good thing - 
it would be an awfully impoverished programming language if it could 
only be used for the purposes its creators intended!

I realize that you are trying to hold back the chaos of everyone wanting 
to put their half-baked idea into Python's syntax and I appreciate that. 
However, there are two ways to accomplish this, which I would call a 
'soft' prohibition whereby you set usage guidelines and style rules, and 
the 'hard' prohibition where you make it physically impossible to 
violate the rules. The problem with the 'soft' method is obvious - since 
the rules are only enforced by social contract, people can break them. 
The problem with the 'hard' method is that you may be closing off cases 
where it would be reasonable to make an exception to the rule - in other 
words, you are taking the decision out of the hands of the potential 
rule-breakers, which in some instances may have better judgment in a 
particular case than you do.

For class-definition keyword arguments, I am envisioning that there 
would be some opportunities for useful innovations using this syntax, 
although I don't know what those might be. (If I knew, then they 
wouldn't be innovations!) Moreover, by granting people this 'hook', we 
would be allowing people to accomplish things that they would otherwise 
have to lobby for syntactical changes to accomplish.

With respect to holding back the chaos, I'm all in favor of 'soft' 
prohibitions here - i.e. guidelines as to when this feature ought to be 
used. For one thing, anything that can be done via class decorator 
instead of a metaclass ought to use the former rather than the latter 
IMHO. The new metaclass mechanism should only be used when you need to 
'go deep' - in other words, when you need to make a customization to the 
class that fundamentally alters its representation.

-- Talin