Understanding Monkey Patching
I’ve noticed one of the problems I have writing this blog is that I prefer to have finished thoughts when I write up something, or at least to have a good understanding of a problem I am working on before committing it to ‘paper’. Unfortunately, this doesn’t lead to many updates. I’ll try to break this habit a little. Recently I heard the term ‘Monkey Patching’ after one of the Seattle Patterns Group meetings, in relation to Ruby on Rails.
A Monkey-Patch (also called Monkey Patch, MonkeyPatch) is a way to extend or modify runtime code without altering the original source code for dynamic languages (e.g. Ruby and Python).
Today, reading a blog entry from Chad Fowler, the term came up again with a Python developer saying:
You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it “monkeypatching”. In Ruby they call it “opening a class” and think it’s a cool feature. I will assert: we are right, they are wrong.
When I read that, I felt almost relieved, because I was thinking the same thing. I can see a limited use for it, but it seems like something you should only do in dire circumstances, that it would be detrimental to good software engineering practices. I can’t prove this, nor am I totally convinced, but Ruby and Ruby on Rails in particular seems to play a little bit fast and loose. I suppose this fits in with Agility, but there does seem to be a mental divide between Python and Ruby people (even though they are really quite close linguistically). To date, I’m much more in the Python camp, but I’ve been deploying Rails apps at work, and I’ll be delving more into Ruby as I go forward. I have heard rumors that Zope does Monkey Patching, and this convinces me even more. Zope has almost single handedly destroyed Python’s reputation at my place of work. Thanks Zope!
Years later, I built my own language with a protocol system for operator dispatch — a more structured approach to the same extensibility that monkey patching provides.
Comments
I'm not sure who will blame Zope for Python's reputation (as Zope has quite a good reputation, see for example Plone, Zope's best known product). Also, I'm pretty sure monkeypatching is just as disregarded in Zope as it is in the rest of Python. Yes, monkeypatching is done in Zope (mostly by Plone and add-ons, from my knowledge), but it's wrong to say that "Zope does Monkey Patching". Zope can do it just like any other Python software.
Zope 3 (Zope community's next effort in developing a web platform) goes a long way in fixing Zope 2 shortcomings. Hopefully this would increase Zope's reputation in the Python community.
Yes, Plone does have a good reputation, I guess the main problem we have with Zope at work is an application built on Zope is always breaking. Probably not fair to blame Python or Zope, but that's human nature, I suppose.
Funny is, I'm a Plone developer and I ended up here because I needed to patch Zope 2.9.8 and doing a monkeypatch is the fastest solution to check if your solution works before applying for a patch to Zope itself.
When finally we'll be able to get rid of Zope 2 and we'll get to Zope 3, there will be no need to monkeypatch again.
Also, I can understand much of the diffidence that surrounds Zope, being that version 2 was rather cryptic at times and version 3 is more a J2EE class product than a quick-and-agile framework (although MUCH more agile than J2EE, and offering almost all of the feature of it)