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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
