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

[Phillip J. Eby]

At 02:56 PM 5/10/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Which is an excellent demonstration, by the way, of another reason
> > why before/after methods are useful.  They're all *always* called
> > before and after the primary methods, regardless of how many of them
> > were registered.
>
>But unless I'm mistaken, ClassC can still take over the
>whole show using a method that doesn't call the next
>method.

No, because you're still thinking of "before" and "after" as if they 
were syntax sugar for normal method chaining.  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.  This is one of the 
reasons they're useful to have, in addition to normal and "around" methods.


> >     debug = Debug.make_decorator('debug')
> >     always_overrides(Debug, Around)
> >     always_overrides(Debug, Method)
> >     always_overrides(Debug, Before)
> >     always_overrides(Debug, After)
>
>This is getting seriously brain-twisting. Are you saying
>that this somehow overrides the subclass relationships,
>so that an @Debug method for ClassA always gets called
>before other methods, even ones for ClassC?

Just like all the Around methods are always called before the before, 
after, and primary methods, and just like all the before methods are 
always called before the primary and after methods, etc.

This was all explicitly spelled out in the PEP:

   ``@before`` and ``@after`` methods are invoked either before or after
   the main function body, and are *never considered ambiguous*.  That
   is, it will not cause any errors to have multiple "before" or "after"
   methods with identical or overlapping signatures.  Ambiguities are
   resolved using the order in which the methods were added to the
   target function.

   "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.

   "After" methods are invoked in the *reverse* order, after all of the
   function's "primary" methods are executed.  That is, they are executed
   least-specific methods first, with ambiguous methods being executed in
   the reverse of the order in which they were added.

In particular, note the last sentence of the second paragraph, and 
the first sentence of the third paragraph.


>Also, you still can't completely win, as someone could
>define an @UtterlySelfish decorator that takes precedence
>over your @Debug decorator.

So?  Maybe that's what they *want*.  Sounds like "consenting adults" to me.


>For that matter, what if there is simply another
>decorator @Foo that is defined to always_override
>@Around? The precedence between that and your
>@Debug decorator then appears to be undefined.

If so, then you'll get an AmbiguousMethods error (either when 
defining the function or calling it) and thus be informed that you 
need another override declaration.