class Foo(object):
pass
foo = Foo()
def bar(self):
print 'bar'
Foo.bar = bar
foo.bar() #bar
Coming from JavaScript, if a "class" prototype was augmented with a certain attribute. It is known that all instances of that "class" would have that attribute in its prototype chain, hence no modifications has to be done on any of its instances or "sub-classes".
In that sense, how can a Class-based language like Python achieve Monkey patching?
The real question is, how can it not? In Python, classes are first-class objects in their own right. Attribute access on instances of a class is resolved by looking up attributes on the instance, and then the class, and then the parent classes (in the method resolution order.) These lookups are all done at runtime (as is everything in Python.) If you add an attribute to a class after you create an instance, the instance will still "see" the new attribute, simply because nothing prevents it.
In other words, it works because Python doesn't cache attributes (unless your code does), because it doesn't use negative caching or shadowclasses or any of the optimization techniques that would inhibit it (or, when Python implementations do, they take into account the class might change) and because everything is runtime.
I just read through a bunch of documentation, and as far as I can tell, the whole story of how foo.bar
is resolved, is as follows:
foo.__getattribute__
by the following process? If so, use the result of foo.__getattribute__('bar')
.
__getattribute__
will not cause infinite recursion, but the implementation of it might.)__getattribute__
in new-style objects, as a default implementation is provided in object
- but that implementation is of the following process. ;) )__getattribute__
method in Foo
, and access foo.__getattribute__
, foo.__getattribute__('__getattribute__')
will be called! But this does not imply infinite recursion - if you are careful ;) )bar
a "special" name for an attribute provided by the Python runtime (e.g. __dict__
, __class__
, __bases__
, __mro__
)? If so, use that. (As far as I can tell, __getattribute__
falls into this category, which avoids infinite recursion.)bar
in the foo.__dict__
dict? If so, use foo.__dict__['bar']
.foo.__mro__
exist (i.e., is foo
actually a class)? If so,
base
in foo.__mro__
[1:]:
foo
itself, which we already searched.)bar
in base.__dict__
? If so:
x
be base.__dict__['bar']
.x.__get__
?
x.__get__(foo, foo.__class__)
.bar
is, itself, an object, and the Python compiler automatically gives functions a __get__
attribute which is designed to be used this way.)x
.base
of foo.__class__.__mro__
:
foo.__class__.__mro__[0]
will always be foo.__class__
, i.e. Foo
in our example.)foo.__mro__
exists. This is because classes have a class, too: its name is type
, and it provides, among other things, the method used to calculate __mro__
attributes in the first place.)bar
in base.__dict__
? If so:
x
be base.__dict__['bar']
.x.__get__
?
x.__get__(foo, foo.__class__)
.bar
is, itself, an object, and the Python compiler automatically gives functions a __get__
attribute which is designed to be used this way.)x
.foo.__getattr__
by the preceding process? If so, use the result of foo.__getattr__('bar')
.raise AttributeError
.bar.__get__
is not really a function - it's a "method-wrapper" - but you can imagine it being implemented vaguely like this:
# Somewhere in the Python internals
class __method_wrapper(object):
def __init__(self, func):
self.func = func
def __call__(self, obj, cls):
return lambda *args, **kwargs: func(obj, *args, **kwargs)
# Except it actually returns a "bound method" object
# that uses cls for its __repr__
# and there is a __repr__ for the method_wrapper that I *think*
# uses the hashcode of the underlying function, rather than of itself,
# but I'm not sure.
# Automatically done after compiling bar
bar.__get__ = __method_wrapper(bar)
The "binding" that happens within the __get__
automatically attached to bar
(called a descriptor), by the way, is more or less the reason why you have to specify self
parameters explicitly for Python methods. In Javascript, this
itself is magical; in Python, it is merely the process of binding things to self
that is magical. ;)
And yes, you can explicitly set a __get__
method on your own objects and have it do special things when you set a class attribute to an instance of the object and then access it from an instance of that other class. Python is extremely reflective. :) But if you want to learn how to do that, and get a really full understanding of the situation, you have a lot of reading to do. ;)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With