Method objects question

Ben Caradoc-Davies bmcd at
Tue Nov 23 21:49:23 CET 1999

On 23 Nov 1999 17:01:53 GMT, Donn Cave <donn at> wrote:
>It doesn't seem to matter where a function is defined, only the scope
>where it's found.  The normal and most convenient way to get a function
>into the class name space is certainly to define it there, but any other
>way will serve as well - it doesn't matter if you define it outside the
>class, or inside.
>How could we justify anything different, in a dynamic "run time" system
>like Python?

Sure, the class behavious is excellent. But the point is, why should functions
found in a class namespace be converted into methods, but functions found in an
instance namespace not converted?

For example, suppose you have a running application containing two instances of
the same class. You need to patch your application on the fly, performing
*different* modifications on each object. You send a signal to your
application, and when it is next idle it execfiles your patch script.

This script can modify each instance's variables, rebinding them to entirely
new objects. In particular, it is possible to hide class variables by adding
instance variables of the same name. However, with the current behaviour, it is
not possible to bind instance variables to function objects and override class
variables with the same name (bound to function objects) without changing any
other code, because the rest of the program will expect these instance
atributes to be *method objects*, not ordinary function objects. It is only
possible to change the class variable, and thus change the behaviour of *all*
instances of that class.

In a nutshell, I don't see any fundamental reason why the
search-instance-namespace then search-class-namespace attribute resolution
order couldn't be used to allow method overriding on an instance-by-instance
basis. With the current, function-to-method conversion rules, this is

Actually, I'm more curious about why this design decision was made. (Or did it
just happen that way!)

Ben Caradoc-Davies <bmcd at>

More information about the Python-list mailing list