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

Phillip J. Eby pje at telecommunity.com
Sun Jul 22 03:58:49 CEST 2007

At 01:28 PM 7/22/2007 +1200, Greg Ewing wrote:

Phillip J. Eby wrote: > Well, I've worked with people who dislike OO for exactly the same > reason, since they feel they can never know whether a method might > have been overridden in a subclass.

I think there's a considerable difference in degree here, though. When you call a method, you know you're delegating responsibility to the object for carrying out that operation. And you know you're delegating it to that object and no other, so given the run-time type

Well, if you're looking at run-time, then you can equally well dump out the runtime contents of a generic function, complete with modules, filenames, and line numbers of every method. In the peak.rules.core case, that operation would look something like:

 from peak.rules.core import rules_for
 print list(rules_for(somefunc))

Although you'd probably want nicer formatting. But that wouldn't be hard to add.

If any function can be overloaded, then any call could potentially be delegating somewhere, increasing the range of possible behaviours even more.

That's exactly true of today's Python, and always has been. Heck, somebody can change a class' bases at runtime, or change the class of an object on the fly.

I don't think that anybody's saying that unrestricted use of dynamism is good, or that it can't be abused. However, the potential for abuse is no different. If anything, generic functions allow more structured dynamism, because two different modules can safely add methods to a function, instead of being tempted to reimplement and monkeypatch it.

More information about the Python-3000 mailing list