[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

Phillip J. Eby pje at telecommunity.com
Thu May 10 18:16:02 CEST 2007

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.makedecorator('debug') > alwaysoverrides(Debug, Around) > alwaysoverrides(Debug, Method) > alwaysoverrides(Debug, Before) > alwaysoverrides(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 alwaysoverride @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.

More information about the Python-3000 mailing list