[Python-3000] pep 3124 plans (original) (raw)

Guido van Rossum guido at python.org
Fri Jul 27 17:25:18 CEST 2007

On 7/26/07, Jeffrey Yasskin <jyasskin at gmail.com> wrote:

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): defaultstuff(self) @after(mymethod) def later(self): morestuff(self) class MyDerived(MyBase): mymethod = MyBase.mymethod @overload def mymethod(self): otherstuff(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?

The more I think about this example (and the one in the PEP from which it's derived), the more I think this part is a frontal collision between two paradigms, and needs a lot more thought put into it. The need to say "mymethod = MyBase.mymethod" in the subclass, and the subtle disasters that happen if this is forgotten, and the rules that guide what code is called in what order when a subclass method is called with a type signature for which a better match exists in the base class, not to mention the combination of super() with next_method, all make me think that ths part of the PEP is not ready for public consumption just yet.

Basic GFs, great. Before/after/around, good. Other method combinations, fine. But GFs in classes and subclassing? Not until we have a much better design.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list