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