[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
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
# NormalA gets skipped, unless NormalB calls it explicitly
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
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.
More information about the Python-3000