The following should work: import thirdpartymodule_a import thirdpartymodule_b def new_init(self): self.a = 43 thirdpartymodule_a.SomeClass.__init__ = new_init thirdpartymodule_b.dosomething() If you want the new init to call the old init replace the new_init() definition with the following: old_init = thirdpartymodule_a.SomeClass.__init__ def new_init(self, *k, **kw): old_init(self, *k, **kw) self.a = 43
The best explanation I heard for Monkey patching/Duck-punching is by Patrick Ewing in RailsConf 2007 …if it walks like a duck and talks like a duck, it’s a duck, right? So if this duck is not giving you the noise that you want, you’ve got to just punch that duck until it returns what you … Read more
import module class ReplaceClass(object): …. module.MyClass = ReplaceClass
It should be noted that several of the answers here will patch the decorator for the entire test session rather than a single test instance; which may be undesirable. Here’s how to patch a decorator that only persists through a single test. Our unit to be tested with the undesired decorator: # app/uut.py from app.decorators … Read more
The problem is that prototype can be modified in several places. For example one library will add map method to Array’s prototype and your own code will add the same but with another purpose. So one implementation will be broken.
I suppose I should expand this answer, now that I’m older and wiser and know what’s going on. Better late than never. You can add a property to a class dynamically. But that’s the catch: you have to add it to the class. >>> class Foo(object): … pass … >>> foo = Foo() >>> foo.a … Read more
No, you cannot. In Python, all data (classes, methods, functions, etc) defined in C extension modules (including builtins) are immutable. This is because C modules are shared between multiple interpreters in the same process, so monkeypatching them would also affect unrelated interpreters in the same process. (Multiple interpreters in the same process are possible through … Read more
You can’t directly add the method to the original type. However, you can subclass the type then substitute it in the built-in/global namespace, which achieves most of the effect desired. Unfortunately, objects created by literal syntax will continue to be of the vanilla type and won’t have your new methods/attributes. Here’s what it looks like … Read more
As I said in a comment to your question, after looking at the json module’s source code, it does not appear to lend itself to doing what you want. However the goal could be achieved by what is known as monkey-patching (see question What is a monkey patch?). This could be done in your package’s … Read more
EDIT: It has been 9 years since I originally wrote this answer, and it deserves some cosmetic surgery to keep it current. You can see the last version before the edit here. You can’t call the overwritten method by name or keyword. That’s one of the many reasons why monkey patching should be avoided and … Read more