[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
jason.orendorff at gmail.com
Wed May 2 04:43:22 CEST 2007
On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:22 PM 5/1/2007 -0400, Jason Orendorff wrote:
> >I think I would prefer to *always* pass the next method
> >to @around methods, which always need it, and *never*
> >pass it to any of the others. What use case am I missing?
> Calling the next method in a generic function is equivalent to calling
> super() in a normal method. Anytime you want to add more specific behavior
> for a type, while reusing the more general behavior, you're going to need
> it. [...]
Oh, I see. I thought @before, @after, and @around should cover all
the use cases. But timing is not the only difference between them.
It also affects how you affect other people's advice and how later,
more specific advice will affect you. In short, you have to ask
yourself: am I hooking something (before/after), implementing it
(when), or just generally looking for trouble (around)?
I haven't used CLOS or Aspect-J, but I have played Magic: the
Gathering, which judging by these examples is largely the same
thing. Incidentally, Magic gets by with just @around (which they
spell "instead of") and @after (which they spell "when").
Come to think of it, Inform 7 is the other system I know of that has
an advice system like this. Now I'm suspicious. Are you trying to
turn Python into some kind of game?
I forgot to say earlier: Thanks very much for writing this PEP.
This should be interesting.
> The other possibility would be to clone the functions using copied
> func_globals (__globals__?) so that 'next_method' in those namespaces would
> point to the right next method. But then, if the function *writes* any
> globals, it'll be updating the wrong namespace. Do you have any other ideas?
Here's what I've got left. Take your pick:
def bisect_bee(nextMethod, seq : Sequence, eric : Bee, *options):
..in which case @override would be left out in the cold, but I'm okay
with that. Or else:
def bisect(nextMethod, ...): ...
Your idea of using the argument annotation was fine, too. Any
of these three is better than detecting the argument name.
More information about the Python-3000