Portrait of a "real life" __metaclass__

[Jonathan Gardner]

On Nov 9, 7:12 pm, Mark Shroyer <usenet-m... at markshroyer.com> wrote:
> I guess this sort of falls under the "shameless plug" category, but
> here it is: Recently I used a custom metaclass in a Python program
> I've been working on, and I ended up doing a sort of write-up on it,
> as an example of what a "real life" __metaclass__ might do for those
> who may never have seen such a thing themselves.
>
> http://markshroyer.com/blog/2007/11/09/tilting-at-metaclass-windmills/
>
> So what's the verdict?  Incorrect?  Missed the point completely?
> Needs to get his head checked?  I'd love to hear what
> comp.lang.python has to (anthropomorphically) say about it.
>

Kinda wordy. Let me see if I got the point:

- You already had a bunch of classes that did age matching on date
time objects.

- You were building a class that matched emails.

- You wanted to reuse the code for age matching to do email matching
(based on the message's age)

- So you wrote a metaclass that replaced the match() method with a
proxy that would either dispatch to the old match() method (if it was
a datetime object) or dispatch to the new match() method (which
matched based on the message's date.)

Sounds Java-y, if that's even a word. Too many classes, not enough
functions. You can tell you are doing Java in Python when you feel the
urge to give everything a name that is a noun, even if it is
completely based of a verb, such as "matcher". My opinion is that if
you want to talk about doing something in Python such as matching,
starting writing functions that match and forget the classes. Classes
are for real nouns, nouns that can do several distinct things.

What would I have done? I wouldn't have had an age matching class. I
would have had a function that, given the datetime and a range
specification, would return true or false. Then I would've written
another function for matching emails. Again, it takes a specification
and the email and returns true or false.

If I really wanted to pass around the specifications as objects, I
would do what the re module does: have one generic object for all the
different kinds of age matching possible, and one generic object for
all the email objects possible. These would be called,
"AgeMatchSpecification", etc... These are noun-y things. Here,
however, they are really a way of keeping your data organized so you
can tell that that particular dict over there is an
AgeMatchSpecification and that one is an EmailMatchSpecification. And
remember, the specifications don't do the matching--they merely tell
the match function what it is you wanted matched.

Now, part of the email match specification would probably include bits
of the date match specification, because you'd want to match the
various dates attached to an email. That's really not rocket science
though.

There wouldn't be any need to integrate the classes anymore if I did
it that way. Plus, I wouldn't have to remember a bunch of class names.
I'd just have to remember the various parameters to the match
specification for age matching and a different set of parameters for
the email matching.