[Python-3000] rethinking pep 3115

[Alex Martelli]

On 6/10/07, tomer filiba <tomerfiliba at gmail.com> wrote:
> pep 3115 (new metaclasses) seems overly complicated imho.

It does look over-engineered to me, too.

> 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.

Agreed, but it doesn't look very elegant.

>
> 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.

I like this one, with classdict being the keyword (dict is the name of
a builtin type and we shouldn't encourage the frequent but iffy
practice of 'overriding' builtin identifiers).

>
> 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.

I agree with your observations and with your hope.


Alex