[Python-3000] pep 3124 plans
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:
> def mymethod(self):
> def later(self):
> class MyDerived(MyBase):
> mymethod = MyBase.mymethod
> def mymethod(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