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

Jim Jewett jimjjewett at gmail.com
Fri May 11 15:46:19 CEST 2007

On 5/10/07, Phillip J. Eby <pje at telecommunity.com> wrote:

At 09:59 AM 5/11/2007 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: >>As I said above (and in the PEP), all before and after methods >>are always called, unless an exception is raised somewhere along the way.

>> "Before" methods are invoked most-specific method first, with >> ambiguous methods being executed in the order they were added. All >> "before" methods are called before any of the function's "primary" >> methods (i.e. normal @overload methods) are executed.

As much as it seems clear once you understand ... it isn't, if only because it is so unexpected. I think it needs an example, such as

class A: ...
class B(A): ...

Then register before/after/around/normal methods for each, and show the execution path for a B(). As I understand it now (without rereading the PEP)

AroundB part 1
AroundA part 1
BeforeA
BeforeB
NormalB
# NormalA gets skipped, unless NormalB calls it explicitly
AfterA
AfterB
AroundA part 2
AroundB part 2

But maybe it would just be AroundB, because an Around is really a replacement?

>I can see a problem with this. If Library1 defines a >method that always overrides an @around method, and >Library2 does the same thing, then if I try to use >both libraries at the same time, I'll get an exception >that I don't know the cause of and don't have any >idea how to fix.

Actually, that would require that Library1 and Library2 both add methods to a generic function in Library3. Not only that, but *those methods would have to apply to the same classes*. So, it's actually a lot harder to create that situation than it sounds.

In particular, notice that if Library1 only uses its combinators for methods applying to its own types, and Library2 does the same, they cannot create any method ambiguity in the third library's generic functions!

Library 1 and Library 2 both register Sage classes with Numpy, or vice versa. Library 1 and 2 don't know about each other. Library 1 and 2 also go through some extra version skew pains when Sage starts registering its types itself.

hmm... if Library 2 is slightly buggy, or makes a slightly different mapping than library 1, then my getting correct results will depend on which of Library 1/Library 2 gets imported first -- or, rather, first got to the registration stage of their being imported.

-jJ

More information about the Python-3000 mailing list