[Python-3000] Metaclasses in Python 3000: Draft 2

[Talin]

Guido van Rossum wrote:
> While you're at it, could you also add a pointer to this patch as a
> sample implementation?
> 
> http://python.org/sf/1681101
> 
> It's far from complete at this point; so far, I've got the syntax
> working and it seems to compile old code just fine, but the keyword
> args and */** notation are simply ignored. If someone wants to work on
> this, drop me a note to see if I haven't made progress already.
> 
> --Guido

That is way cool.

One other thing that I think might be good to have (at some point after 
we get a working implementation) is some sort of HOWTO document (apart 
from the PEP) that lays out a set of guidelines or advice on creating 
metaclasses. Perhaps a Python cookbook recipe or something.

The reason I say this is because one of the things that I noticed is 
that writing a metaclass that handles all corner cases properly can be 
quite tricky. As an example, if you're doing anything with ordered 
fields, you need to make sure that the base class's ordered fields are 
properly incorporated into the calculation.

Exploiting the new metaclass mechanism fully requires a deeper knowledge 
of the way function bodies are evaluated and how the type() constructor 
works. The fact that there was some confusion as to what methods of the 
dict interface needed to be supported is evidence of this.

The PEP gives you a mechanism for declaring and using metaclasses, and 
invites you to play with the class machinery at a deeper level, but it 
doesn't tell much about the internal mechanism and structure of classes 
themselves, or what is/isn't valid in terms of tweaking them. Thus, for 
example, if I want a class whose instances don't have a dictionary, but 
instead store their members in a flat array (a la __slots__), I would 
need to know what parts of the system will choke, expecting a dict to be 
there when there isn't one, and how to get around that.

-- Talin