[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

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 this pattern.

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 mailing list