[Python-3000] rethinking pep 3115

tomer filiba tomerfiliba at gmail.com
Sun Jun 10 01:32:05 CEST 2007


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070610/a2c7369a/attachment.htm 


More information about the Python-3000 mailing list