[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Jim Jewett]

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