Michele said:
I gave a look at your transparancies and they are very good,
indeed.
Thanks.
Still, there a couple of minor points I think
could be improved, for the sake of metaclass newbies
(I am in a nitpick mood today
Rassin-frassin...
1) On page 26 you say:
Note: In Python 2.2.3, the meta-class object's __call__ is
not called by the metaclass hook, the interpreter calls
__new__, then __init__ directly
That's correct (and true in 2.3 too), still there is a way
to get the metaclass hook to call __call__: it involves
meta-metaclasses
Good thing this didn't occur to me before I gave the presentation, it
already ran 2 hours instead of 20 minutes
. I'd been thinking Guido
was just messing with people's minds when he said the meta-class was
called. My bad.
....
in this example MetaMeta.__call__ is a meta-metamethod, which is
accessible
to Meta, but not to its instance C; therefore you can modify the C
__call__
(and Meta.__call__ too, if you wish) method independently from
MetaMeta.__call__, avoiding name clashes.
Probably have to cover this a good long way through the presentation, or
it'll just lose people who are just beginning to get comfortable with
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 )
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.
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".
2) On page 30 you say that you can modify the dictionary both in
__new__ and in __init__. This is true, but not obviously true.
In __new__ you can simply change "dic", in __init__ this would not
work:
....
You can modify the dict only indirectly, with something like
cls.spam='egg'.
Yes, wishful thinking on my part
. Back to that old "there's no hook
to set an attribute in the dictionary of a class without going through
the descriptors mechanism" problem. I should have explicitly noted that
you can modify *attributes* of the class object inside __init__, instead
of describing the process as modifying as the dictionary of the class.
(Done now). Challenge is that people will then get away from mentally
modelling the class as a dictionary with some extra fields.
For the rest, excellent presentation!
Thanks again. We seemed to get through it without any heads exploding,
and hopefully everyone in the audience now understands them at least
well enough to be able to guage when/if then need them, and what's going
on under the covers if a meta-programmer is using them to provide
services in some library.
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).
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.
Anyway, thanks for the feedback, tweaked slides now available from the
same location.
Enjoy,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/