[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Wed May 16 02:41:38 CEST 2007
At 12:19 PM 5/16/2007 +1200, Greg Ewing wrote:
>Christian Tanzer wrote:
> > Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > > Phillip J. Eby wrote:
> > >
> > > > Imagine what would happen if the results of
> > > > calling super() depended on what order your modules had been
> imported in!
> > >
> > > Actually, something like this does happen with super.
> > This is true but doesn't matter (which is the beauty of super).
>Only because super methods are written with this
>knowledge in mind, however. Seems to me you ought
>to have something similar in mind when overloading
>a generic function.
This discussion has wandered away from the point. Next-method calls
are in fact identical to super calls in the degenerate case of
specializing only on the first argument.
However, the point of before/after methods is that they don't follow
If only one person is writing all the methods in a generic function,
they don't have much benefit from using before/after methods, because
they could just code the desired behavior into the primary methods.
The benefit of before/after, on the other hand, is that they allow
any number of developers to "hook" the calling of the function. Any
given developer can predict the calling order for *their* before and
after methods, but does not necessarily know when other developers'
before/after methods might be called.
If you and I both define a @before(foo,(X,Y)) method, there is no way
for either of us to predict whose method will be called first, even
though we can each predict that our own (X,Y) method will be called
before an (object,object) method that we also registered. Our
methods are in parallel universes that do not overlap.
This is the driving force for having before and after methods:
allowing independent hooks to be registered, while ensuring that they
can't mess anything up (as long as they stick to their own business).
To put it another way, if you care about the *overall* (absolute?)
order, you have to use primary or "around" methods. If you only care
about the *relative* order, you want a before or after method. The
fact that you do NOT have explicit control over the chaining is the
very thing that makes them able to be independent.
More information about the Python-3000