http://www.catb.org/esr/jargon/html/P/patch.html

Of course, that’s just my own understanding of monkey patching, lots of people have been using the term to mean dynamic modification to classes at runtime with other intents than as a patch. But two definitions of the term leaves it open for folks to get upset for no good reason though. If I say, “monkey patching is good for quick and dirty fixes” and I mean monkey patch *only* as “patch”, and someone else hears that and understands monkey patching to mean any type of dynamic class modification, then it sounds like I am saying, “dynamic class modification is only useful as a guick and dirty fix” – which isn’t true :(

Take your example of faking out code for testing purposes. I may well find this to be an elegant, concise solution to your testing problem. But should it be called monkey patching if it’s intent is as a permanent solution?

I would just like to add that there even gorilla patching has it’s uses. I fake out bits of SQLAlchemy during testing sometimes, and I’ve got a mokeypatched cherrypy wsgi server that we delivered to a client on a very tight deadline, and very specific requirements.

And you are right to say that Inversion of Controll and Dependency Injection don’t require monkeypatching and are therefore totally seprate ideas — but they do provide use-cases for dynamically monkeying around with classes. I was not at all clear about that. ;)

Considering that this term originated from Zope, which embraced magic such as acquisition, casual monkey patching is considered harmful, while other forms of metaprogramming and dynamic trickery were not (at least back in the 90′s and early 2000′s, Zope has mostly moved to an explicit is better than implicit attitude). Monkey patches are a good way of expressing, “we should change this framework code, try it out in your sandboxes before we include it in trunk and see if it causes any problems.”

Plone’s Archetypes for example generates methods dynamically based on a schema declaration, but this is never referred to as monkey patching.

Inversion of Control is something that is common to almost all frameworks, it sounds rather fancy but it just means that some portion of the control flow of your application is handled by library or framework code. As Martin Fowler explains, even simple libraries such as Tk perform Inversion of Control (http://martinfowler.com/bliki/InversionOfControl.html). Dependency injection is more specific form of Inversion of Control where the control flow that is being handled by the framework is how pluggable/swapable implementations are being chosen. Dependency Injection can be defined as, “the implementation of one class is performed partially by object(s) supplied by the framework”.

And they are. They are useful tools. Python has a bit of nasty monkey-in-the-mouth taste from bad monkeypatching experiences which were hard to understand and debug. And there is some truth to that. Metaprogramming in general can make debugging more interesting.

If we still built housed out of straw and mud, home repairs would be super cheep and easy too. But, me I’m still gonna use my low flow toilets, insulated walls, electric wiring, and polyvinyl siding, even though those things are more difficult to debug and more expensive to replace.

My point, is that in software, as everywhere else, it’s all about trade-offs.