Metaclasses presentation slides available...

[Mike C. Fletcher]

Slides from my PyGTA presentation on Tuesday, focusing mostly on
why/where you would want to use meta-classes, are available in PDF format:

http://members.rogers.com/mcfletch/programming/metaclasses.pdf

BTW, for those not on Python-list, be sure to check out David &
Michele's newest developerworks article on the topic:

http://www.ibm.com/developerworks/library/l-pymeta.html

http://www.ibm.com/developerworks/library/l-pymeta2/?ca=dnt-434

Have fun,
Mike

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/

[Alex Martelli]

Re: Metaclasses presentation slides available...

Mike C. Fletcher wrote:
[color=blue]
> Slides from my PyGTA presentation on Tuesday, focusing mostly on
> why/where you would want to use meta-classes, are available in PDF format:
>
> http://members.rogers.com/mcfletch/p...etaclasses.pdf
>
> BTW, for those not on Python-list, be sure to check out David &
> Michele's newest developerworks article on the topic:
>
> http://www.ibm.com/developerworks/library/l-pymeta.html
> http://www.ibm.com/developerworks/li...a2/?ca=dnt-434[/color]

Which reminds me -- my own presentations from this summer's
conferences, including one on metaclasses, are _also_ online now --
I should have announced that when they were put online but forgot,
being distracted by business trips &c.

See http://www.strakt.com/dev_talks.html for links to all of them.


Alex

[Mike C. Fletcher]

Re: Metaclasses presentation slides available...

Michele Simionato wrote:
[color=blue]
>"Mike C. Fletcher" <mcfletch@roger s.com> wrote in message news:<mailman.1 062101481.30815 .python-list@python.org >...
>
>[color=green]
>>Slides from my PyGTA presentation on Tuesday, focusing mostly on
>>why/where you would want to use meta-classes, are available in PDF format:
>>
>> http://members.rogers.com/mcfletch/p...etaclasses.pdf
>>
>>[/color]
>
>I gave a look at your transparancies and they are very good,
>indeed.
>[/color]
Thanks.
[color=blue]
>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 ;)
>[/color]
Rassin-frassin... ;) :)
[color=blue]
>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 ;)
>[/color]
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.
....
[color=blue]
>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.__cal l__, avoiding name clashes.
>[/color]
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".
[color=blue]
>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:
>
>[/color]
....
[color=blue]
>You can modify the dict only indirectly, with something like
>cls.spam='egg' .
>[/color]
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.
[color=blue]
>For the rest, excellent presentation!
>[/color]
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.
[color=blue]
>You forgot to mention Alex Martelli's presentation:
>
>http://www.strakt.com/dev_talks.html
>[/color]
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/

[Alex Martelli]

Re: Metaclasses presentation slides available...

Mike C. Fletcher wrote:
...[color=blue]
> 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 )[/color]

Almost, but what gets executed is:

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

i.e., the unbound-method type(metaclass) .__call__ *DOES* get the mandatory
first argument 'metaclass', of course.
[color=blue]
> 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.[/color]

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

type(foo).__cal l__(foo, args)

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

[color=blue]
> 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".[/color]

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.__cal l__ is what
determines what it means to call the CLASS, etc, etc.

[color=blue][color=green]
>>You forgot to mention Alex Martelli's presentation:
>>
>>http://www.strakt.com/dev_talks.html
>>[/color]
> 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).[/color]

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

[color=blue]
> 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.[/color]

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