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

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Jul 25 04:39:06 CEST 2007

Phillip J. Eby wrote:

At 12:54 PM 7/24/2007 +1200, Greg Ewing wrote:

When adding an overload to a GF, what methodology can I follow to ensure that my overload doesn't interact in an unfortunate way with another one somewhere else, perhaps one not written by me? What methodology can you follow that ensures that same thing when overriding a method in a subclass?

It's dead simple -- my method always wins.

This is true even in the presence of multiple inheritance. Problems only arise there if I use super() to make an inherited method call (so I don't do that) or if other people multiply inherit from me -- in which case it's their problem, not mine.

Okay, well I guess the above statements all put you squarely in the "OO is too scary" category,

Certainly not -- I don't find OO scary at all. I wouldn't say that I find GFs "scary" either, only that I would use them cautiously and sparingly. I don't agree that there is no difference between the traditional OO model and GFs. With GFs there is less static structure that you can rely on.

And what if the program doesn't exist yet, because I'm still thinking about how to write it? Or it exists but isn't yet in a state where it can be run successfully? I don't understand what you're asking, here.

Don't you think it's important to be able to reason about the way a program will behave while you're in the process of designing it? If you haven't written runnable code yet, you can't run it to get a list of method overrides.

I was under the impression that under certain circumstances, if one object is "more specific" than the other (i.e., one is an instance of a subclass of the other's type), then that one gets first say.

You may be right. But the fact remains that the method called will be a method of one class or the other -- it can't be some function defined in an arbitrary place.

-- Greg

More information about the Python-3000 mailing list