[Python-3000] pep 3124 plans

Jeffrey Yasskin jyasskin at gmail.com
Fri Jul 27 07:27:42 CEST 2007


On 7/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> For example, one pattern that sometimes comes up in writing methods
> is that you have a base class that always wants to do something
> *after* the subclass version of the method is called.  To implement
> that without method combination, you have to split the method into
> two parts, one of which gets called by the other, and then tell
> everybody writing subclasses to only override the second method.
>
> With method combination and a generic function, you simply declare an
> @after method for the base type, and it'll get called after the
> normal methods for any subclasses.

I've totally wanted to do that, so your email gave me a surge of hope,
but I think the generic function approach is actually worse here
(unless I'm totally misunderstanding). I think this would look like:

class MyBase:
    @generic
    def mymethod(self):
        default_stuff(self)
    @after(mymethod)
    def later(self):
        more_stuff(self)

class MyDerived(MyBase):
    mymethod = MyBase.mymethod
    @overload
    def mymethod(self):
        other_stuff(self)

And if MyDerived just overrides mymethod normally, it replaces the
@after part too.

So instead of telling people to override this other method (with the
benefit that immigrants from other languages are already used to this
inconvenience), you have to tell them to stick two extra lines in
front of their overrides. If they forget, the penalty is the same.
What's the benefit from generic functions here?

-- 
Namasté,
Jeffrey Yasskin


More information about the Python-3000 mailing list