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:
[EMAIL PROTECTED] and [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
