pep 3115 (new metaclasses) seems overly complicated imho.<br>it fails my understanding of "keeping it simple", among other heuristics. <br><br>(1)<br>the trivial fix-up would be to extend the type constructor to take
<br>4 arguments: (name, bases, attrs, order), where 'attrs' is a plain <br>old dict, and 'order' is a list, into which the names are appended <br>in the order they were defined in the body of the class. this way,
<br>no new types are introduced and 99% of the use cases are covered. <br><br>things like "forward referencing in the class namespace" are evil. <br>and besides, it's not possible to do with functions and modules,
<br>so why should classes be allowed such a mischief? <br><br>(2)<br>the second-best solution i could think of is just passing the dict as a<br>keyword argument to the class, like so:<br><br>class Spam(metaclass = Bacon, dict = {}):
<br> ...<br><br>so you could explicitly state you need a special dict. <br><br>following the cosmetic change of removing the magical __metaclass__<br>attribute from the class body into the class header, it makes so<br>
sense to replace it by another magical method, __prepare__.<br>the straight-forward-and-simple way would be to make it a keyword <br>argument, just like 'metaclass'.<br><br>(3)<br>personally, i refrain from metaclasses. according to my experience,
<br>they just cause trouble, while the benefits of using them are marginal. <br>the problem is noticeable especially when trying to understand <br>and debug third-party code. metaclasses + bugs = blackmagic.<br><br>moreover, they introduce inheritance issues. the class hierarchy
<br>becomes rigid and difficult to evolve as the need arises, which <br>contradicts my perception of agile languages. i like to view programming<br>as an iterative task which approaches the final objective after <br>several loops. rigidness makes each loop longer, which is why
<br>i prefer dynamic languages to compiled ones.<br><br>on the other hand, i do understand the need for metaclasses,<br>even if for the sake of symmetry (as types are objects). <br>but the solution proposed by pep 3115, of making metaclasses
<br>even more complicated and magical, seems all wrong to me.<br><br>i understand it's already been accepted, but i'm hoping there's<br>still time to reconsider this before 3.0 becomes final.<br><br><br>-tomer