[Python-3000] Generic function PEP won't make it in time
Phillip J. Eby
pje at telecommunity.com
Thu Apr 26 22:08:25 CEST 2007
At 09:00 AM 4/26/2007 -0700, Talin wrote:
>I kind of wonder about the idea of implementing generic functions using
>generic functions. It's one of those ideas that is so obviously elegant
>and clever, that it's very easy for a programmer to fall in love with.
>As someone who frequently finds himself in a similar situation, I often
>discover later that the clever idea I loved wasn't the most practical.
In this case, it's the reverse; I previously implemented generic functions
the other way around, in RuleDispatch. PEAK-Rules is considerably simpler;
in fact I've been realizing lately that the more "object orientation" I
*remove* from it, the easier it gets to work with.
For example, it's recently become clear that my "TreeBuilder" class (used
to assemble efficient dispatch trees by figuring out what tests come next)
is nothing more than a memoized generic function. Having the class exist
just adds to the number of things you have to subclass when you change
anything, and makes it more complex because you also have to change any
code that *creates* a TreeBuilder to create an instance of your subclass
instead. Making it a generic function makes a bunch of extra bookkeeping
>Now, I may be talking out of my butt here - I don't know much about your
>situation, or what rationales you have for designing things the way that
Pretty simple, really -- RuleDispatch's heavily object-based internal
structure made it brittle and complex to refactor or extend, compared to
the outer layers where it used generic functions. The obvious solution was
to make the inner layers generic also.
The real key, though, was looking at Guido's "overloading" prototype for
Py3K and realizing I didn't need to settle for single-dispatch generics for
the core, or have to try and bootstrap the engine on itself; I could use a
simple implementation like his that did multi-dispatch instead. And so I did.
After some experimentation, I found that you can make any generic function
self-bootstrapping (i.e., usable in its own implementation) as long as your
implementation is re-entrant. That is, if a generic function has to call
itself while a method is being added to it, it must simply call the *last
stable version* of itself, rather than the version it's modifying. This is
actually quite simple to arrange, even in the presence of threads.
>However, I would suggest that you might want to consider what
>your actual, practical needs are, and if there is a way to get them that
>is more straightforward and easy to explain.
Well, I could use some other language of course, but I prefer Python. :)
More information about the Python-3000