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.
> 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? If so, I
think this is all getting way too deeply magical.
Also, you still can't completely win, as someone could
define an @UtterlySelfish decorator that takes precedence
over your @Debug decorator.
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.
--
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED] +--------------------------------------+
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
