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

Phillip J. Eby pje at telecommunity.com
Mon Jul 23 02:48:54 CEST 2007

At 11:47 AM 7/23/2007 +1200, Greg Ewing wrote:

With a normal method call, you can take an assumed run-time type, start at one end and follow things through step by step. That's not so easy with generic functions, for two reasons: (1) all of the arguments can potentially influence where the control flow goes, and (2) the overloading code can be anywhere in the program, not confined to the classes involved.

In order to follow things through with normal method calls, you have to know where a class is in the program, implying that you either search for it, or have read enough of the program to figure it out.

Which of these two things is different with generic functions?

(Meanwhile, if you are "starting at one end" and "follow things through step-by-step", then you are going to step right through all the method definitions, regardless of whether they're standard methods or GF methods.)

I'm not saying this makes GFs impossible to use, but they do make the programmer's world considerably more complicated.

Since they make my world simpler, I'd have to disagree with such a blanket statement. (I imagine the other developers who are using them would similarly disagree.)

If your argument is that it might make it more difficult for you to know what's going on in a poorly-organized program, or make it easier to write a poorly-organized program, I might agree with you.

But I disagree in the general case, because if you're going to be grepping for 'foo', it doesn't matter whether it's a method name or a generic function name -- you're still going to find all the definitions.

You can't just brush these concerns off as being no worse than what OO already provides.

Actually I can, and just did. Grep (or whatever global search tool your editor provides) is your friend. It ain't perfect, but it's just as much required (and equally imperfect) for global analysis of a traditionally-OO program.

More information about the Python-3000 mailing list