Metaclasses presentation slides available...

Alex Martelli aleax at aleax.it
Fri Aug 29 10:27:23 EDT 2003


Mike C. Fletcher wrote:
   ...
> metaclasses and metamethods.  See if I've got this right:
> 
> Class-declaration ends
>     Interpreter finds declared metaclass (via whichever method)
>     Interpreter looks for a __call__ method in type( metaclass
> ).__dict__ .(skipping the dictionary of metaclass due to "special"-ness
> of the name __call__)
>     Interpreter executes type(metaclass).__call__( classname, bases,
> dictionary )

Almost, but what gets executed is:

type(metaclass).__call__(metaclass, classname, bases, dictionary)

i.e., the unbound-method type(metaclass).__call__ *DOES* get the mandatory
first argument 'metaclass', of course.

> Assert: It does this due to the "special method-name lookup" exception
> for new-style types: special methods are looked up in the type without
> lookup in the instance dictionary.

Yep.  Exactly like *ANY* situation of foo(args) turns into:

type(foo).__call__(foo, args)

(except when foo is an instance of a classic-class, where for reasons
of backwards compatibility foo.__call__(args) happens instead).


> Hmm, definitely not something to cover early in the presentation...
> especially when most users haven't yet discovered the special-names
> exception (most programmers still haven't discovered the new features of
> Python 2.2 (hence my metaclass presentation)).  If I were writing a "for
> dummies" book that would definitely have to be a "technical aside".

I think that understanding what "foo(args)" means is VASTLY more
important than grasping metaclasses, for (by far) most practical
programming tasks.  The so-called "special-names exception" (which
is not an exception at all but a perfectly general rule -- on the
contrary, the exception is the behavior of classic-class instances:-)
should be clear to the listeners, otherwise they'll get their
knickers in a serious twist trying to make any real use of what
they learn about metaclasses.  E.g., that metaclass.__call__ is what
determines what it means to call the CLASS, etc, etc.


>>You forgot to mention Alex Martelli's presentation:
>>
>>http://www.strakt.com/dev_talks.html
>>
> Well, hard to forget something you've never heard about before ;) .
> Seems like a slightly more involved presentation, targetted more at
> people trying to create metaclasses (i.e. for meta-programmers).

It's more of a _presentation_ -- just the slides with the
highlights -- while yours is more like an _article_ -- much more
useful as standalone material, because you've got so much text on
each slide (but by the same token, not ideal for projection;-).


> I tried to pitch more at the level of "should you use them", or "why
> would you use them and when", or "what's going on when someone creates a
> meta-class and it shows up in the library I'm using" (i.e. the audience
> being primarily (non-meta) programmers).  That seems to be the area that
> doesn't get discussed as often when discussing metaclasses.

Actually, I do target "why would you use them and when", though you
do that much more widely (mine was a 45-minutes presentation, yours
a 2-hours one, I believe, just from amount of material you have on
your slides), trying to distinguish between canonical uses (quite good)
and non-canonical ones (tempting but IMHO best avoided -- it did seem
to me that Guido, who was in the audience as I presented this at
Europython, broadly agreed, and he did even explicitly bless the
convention of using 'mcl' for a first-method-argument that is a
metaclass, just as 'cls' is used for one that is a class and 'self'
for one that is an instance).


Alex





More information about the Python-list mailing list