metaclass and customization with parameters

[Alex Martelli]

Carlos Ribeiro <carribeiro at gmail.com> wrote:
   ...
> But the problem, in my particular case, was not with metaclasses per
> se, but with understanding the 'big picture'. With all respect for

Tim Peters is on record as saying (I paraphrase by memory...) that
metaclasses are NOT something 99% of Python users should worry about,
anyway.  The Big Picture, on the other hand, IS going to be useful to
just about any user of Python, even a casual one.

> regarding the handling of declarations (classes, modules and
> functions), and that also knows what metaclasses are good for. For

Well, that one IS easy: since there are no declarations (of classes,
modules and functions), the handling of declarations is: none at all.
(How would one handle something that doesn't exist, after all?).

Regarding "what metaclasses are good for" (in Python), that's something
we've mostly had to work out the hard way over the last few years --
perhaps harder for those with some understanding of Smalltalk, because
Python metaclasses are so different from Smalltalk ones that one had to
"unlearn" the Smalltalk-originated ideas first.  Just as somebody who
comes from languages where there are declarations must sort of unlearn
those idea, before they can really get the NON-declaration
sort-of-equivalents in Python...

> This very thread, including the last comments from myself and Alex
> Martelli, is specially illuminating in this respect. It took me a
> while to figure out the obvious -- that there are not 'real' class
> declarations in Python, at least as far as they do exist in C++ or
> Delphi (the languages that I worked with before Python). (btw, I
> really don't know Java, but I feel confident to say that Java is
> probably in the C++ camp here also).

Yep, Java has declarations, not quite like C++ but very close, while
Python doesn't (unless you consider the 'global' statement to be a
"declaration" -- it _is_ in any case a _wart_...;-).

> Figuring out the obvious tend to be a big barrier to the learning
> process. For experienced writers, it tends to be a problem also,
> because it's so obvious that one feels compelled to leave it out of
> the explanation. But that's the issue here -- the fact that what I'm
> freely calling 'class declarations' in Python are not really
> declarations (in the same sense of C++, for example), are just

Well, _this_ experienced writer keeps repeating this fact over and over
and over again in _his_ explanations (e.g., Nutshell p. 32: "Unlike
other languages, Python has no declarations"), but of course that
doesn't help all that much if one's explanations just aren't read.

Some simple google search such as:
<http://groups.google.com/groups?as_oq=declaration%20declarations&safe=i
mages&ie=UTF-8&as_ugroup=comp.lang.python&as_uauthors=martelli&lr=&num=2
0&hl=en>
can further show you that I _ceaselessly_ keep repeating this...
*hundreds* of times...: "def is not a declaration: it's an executable
statement", "Python has no declarations", "For that, you'd need some
kind of declaration. Python does not have declarations", "Right, since
we have no declarations." -- over and over and OVER again.  And there
are just snippets readable in the short google summaries of the FIRST
page out of 351 hits.

So, for once, it seems to me that, on this specific subject at least, I
should be held blameless: far from feeling compelled to leave it out, I
am _obsessive_ about pointing it out again and again and AGAIN.  I don't
think I can do much more to get the point across that "*Python has no
declarations, only executable statements*", except maybe personally seek
out every poster who speaks of "declarations in Python", grab them by
their lapels and shout the truth out in their faces.  Sorry, I get too
many frequent flier miles as it, without adding all of these side trips
too.  If (at least some) experienced writers are doing the best they
possibly can to get this crucial point across, and some readers still
just can't get it no matter what, perhaps it's not all that useful to
blame the writers -- and the READERS should perhaps take SOME
responsibility for listening to the unceasing repetitions in
question...?!


> I have developed my own mental model on this, and it tells me that
> classes in Python are declared in a two-step process: code execution,
> and class creation. As I said, this may be obvious to Python insiders
> (obvious to the point where it's natural and doesn't deserve any
> special explanation), but I assume that it isn't, given:

It's a good model -- execution of the code in the class body, then usage
of the dictionary thus built for the purpose of creating the class
object; pretty close to how Python actually does it.  I'm sorry you had
to develop your own mental model of this, since it IS just what I try to
present on p. 100-101 of the Nutshell (and sundry tutorials &c for which
you can find PDF files at www.strakt.com).  "To execute a class
statement, Python first collects the base classes into a tuple t (an
empty one, if there are no base classes) and executes the class body in
a temporary dictionary d.  Then, Python determines the metaclass M to
use" etc, etc.
 
> a) my own trouble to understand the full implications of it;
> b) the type of questions that pop up in this group;
> c) the surprised look that even old-time pythoneers do when they see
> code such as the 'def __metaclass__(...):' inside a class, or similar
> hacks.

Maybe Tim Peters is right that 99% of Python users need not worry about
metaclasses?  That applies to 99% of old-time pythoneers, too -- it's an
issue of whether you _need_ it, not of whether you could learn about it
if it WAS something you needed.  Many Pythonistas are pragmatic guys and
quite understandably don't want to spend any time or energy learning
about stuff they don't need nor care about.

As for me, I'm leaning towards agreement with Guido, that a metaclass
that's not a type _is_ a hack that's best avoided.  So, a 'def
__metaclass__' is already a code smell.  A nested 'class
__metaclass__(type):' would of course be a completely different issue,
basically an "anonymous metaclass" so to speak, not particularly hackish
IMHO -- for the <1% (if Tim has it right) of Pythonistas who _DO_ need
to worry about metaclasses, of course.


Alex