[Python-3000] pep 3124 plans

[Phillip J. Eby]

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.