From a semi-recent post
by Python programmer Ian Bicking:
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.
Today, I was frustrated by a Rails bug affecting pagination with joins. In
short, it doesn’t work. At all.
Miraculously, (no, it wasn’t a coincidence—it was an actual
miracle) Kevin Clark posted a message to
the Rails Core list right in the middle of this episode
complaining about the exact same problem. He said he was working on a fix.
Jeremy Hopple responded a little over an hour later saying that he had
already submitted a patch for the bug.
Visions of the nasty download/patch process started trudging through my
mind, but I was desperate for a fix so I would have dealt with the
ugliness. I hate hacking my local Rails (I’m running off of trunk
using svn:externals) because I don’t like dealing with what happens
when the change actually gets applied to trunk or dealing with merges for
other changes to the same files. It’s not rocket science to get
working but it’s also not fun.
Looking more closely at Jeremy’s email, he’s also distributing
his patch as a Rails plugin. So:
$ ruby script/plugin install count_limit_assocations
Now my code works. The bug is fixed. The plugin contains essentially
nothing but a file that "monkey patches" some of the Rails core
classes, implementing the changed version of the code.
When the change is merged into the Rails trunk, I’ll just
‘script/plugin remove’ Jeremy’s plugin.
The Rails team is already using plugins like this as a way to get new
functionality into circulation as a kind of proving ground before things
make it into Rails core. And as we see today, it’s also a simple,
painless way to get fixes distributed before they’re reviewed and
committed. Sure, you can do the more obvious thing with plugins and
distribute code that implements new functionality altogether. But this
"monkey patching" thing is seriously powerful and, as an end-usre
in this case, I can say that it makes things better for the users
So Ian, with respect, no…you’re not right.
UPDATE: Ian sent me the following clarification by email (reprinted with
Hi Chad. Saw your post on monkeypatching. Just thought I'd clarify that I don't think that kind of use is wrong, and I do that frequently -- applying a patch at runtime to the objects in memory, instead of the source code on disk. It can be expedient, and certainly a whole lot better than trading patches around. The use I object to that I see in lots of Ruby examples (and maybe isn't indicative of most real Ruby code) is when people add methods to other classes that aren't meant to fix anything, but just because they don't have an object of their own to hang the method off of. I've seen several examples where people add methods to Array to implement some recursive algorithm, instead of using a function. Or Rails adding methods to numbers to create time delta objects (well, it would be good if they *were* time delta objects, but I understand they actually just return seconds as ints, but that's another issue entirely). The term "monkeypatch" is really meant to denote that. It's a patch, a fix, an adjustment to the code. The monkey part has a history (that someone left on my post) that I think more-or-less is meant to indicate a certain subversive intent, or at least playfully but maybe mischievous manipulation. We do it often in Python, but everytime we do it we know we are working around the system and not with it. Which is fine too, but it's not the sort of thing you want as a foundation.