Super, Hooks, and Aspect Oriented Programming
I've been giving some thought to super-calls, and I'm looking to consolidate the common patterns of its use. I think if we can do that, we can find a more concise expression of the different uses. So far I've come up with every use being one or more of the following: - Do something before the super method is called, optionally changing the parameters - Do something after the super method is called, optionally changing the return value - Do something with an exception the function raises - Consume new parameters, used by one or more other hooks in place - Do something instead of calling the super method, if some condition is true (such as a particular parameter being present of a specific type) Can anyone add to this? Are there any restrictions to the combination of usage patterns? Obviously, this doesn't capture them all, but can we capture most of them? If we could, could we wrap them up in some hook library (3rd party or otherwise) @before and @after are common enough ideas for decorators already @catching could be used to catch exceptions raised by the super (or another) method How could these patterns consume extra parameters to hand over to one or more hooks? How do we do this in a way that we the MRO doesn't mess up what parameters we consume at what point? I feel the common patterns we see now are error prone, and finding this concise solution might give us better control. I'd love to see something like this included with a future release, but right now I'm trying to get ideas for what it would look like, so I can build a library and use it, and others can use it, and it can be seen if its even useful in real world practice. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
I think no exploration of super() can be complete without considering
the difference between overriding a constructor (__init__ or __new__)
and overriding a regular method. Another thing to include is the use
of keyword arguments.
Also, have you looked at how other languages do this yet?
--Guido
On Wed, Feb 25, 2009 at 5:55 AM, Calvin Spealman
I've been giving some thought to super-calls, and I'm looking to consolidate the common patterns of its use. I think if we can do that, we can find a more concise expression of the different uses. So far I've come up with every use being one or more of the following:
- Do something before the super method is called, optionally changing the parameters - Do something after the super method is called, optionally changing the return value - Do something with an exception the function raises - Consume new parameters, used by one or more other hooks in place - Do something instead of calling the super method, if some condition is true (such as a particular parameter being present of a specific type)
Can anyone add to this? Are there any restrictions to the combination of usage patterns? Obviously, this doesn't capture them all, but can we capture most of them? If we could, could we wrap them up in some hook library (3rd party or otherwise)
@before and @after are common enough ideas for decorators already @catching could be used to catch exceptions raised by the super (or another) method
How could these patterns consume extra parameters to hand over to one or more hooks? How do we do this in a way that we the MRO doesn't mess up what parameters we consume at what point? I feel the common patterns we see now are error prone, and finding this concise solution might give us better control.
I'd love to see something like this included with a future release, but right now I'm trying to get ideas for what it would look like, so I can build a library and use it, and others can use it, and it can be seen if its even useful in real world practice.
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I think no exploration of super() can be complete without considering the difference between overriding a constructor (__init__ or __new__) and overriding a regular method. Another thing to include is the use of keyword arguments.
I'm not a big fan of @before and @after kinds of things. They gain little over writing out the equivalent code in full, and add more mental baggage to the language to keep in your head. -- Greg
participants (3)
-
Calvin Spealman -
Greg Ewing -
Guido van Rossum