Wandering Thoughts archives

More thoughts on why Python doesn't see much monkey-patching

In yesterday's entry I advanced the idea that a significant part of why Python doesn't see much monkey patching (and Ruby does) is that you can't monkey patch a lot of fundamental Python classes and types because they're implemented in C. In sober hindsight, I think that I'm understating two intangibles (one of which I touched on in passing) in favour of a technical explanation.

First, I think that the effects of culture matter more than I initially thought. Culture plays a strong role in shaping how we write code in a language, both explicit in what people tell you to do and not do and implicit in things like what tutorials present and what approaches they take to solve problems. To invert the saying that you can write Fortran in any language, the reality is that people don't and culture is a good part of why.

Second is the issue of syntax. Ruby has a clear and direct syntax for adding your own methods to outside classes, while Python does not. In Python you have to go out of your way to modify a class after it's been created and the syntax is at least somewhat awkward and indirect. It's probably not longer (in lines) than the Ruby version, but it's certainly less direct and obvious. Since I'm a big believer that syntax matters I think that this can't help but have an effect in the two languages. I don't know if Ruby's syntax steers people towards monkey patching, but how it's both inobvious and a pain in Python has to steer people away from it.

Sidebar: the syntax in each language

In Ruby, monkey patching looks like this:

class SomeClass
  def newfunction
    [whatever]
  end
end

(I believe this is correct; I'm taking it from online examples, since I'm not a Ruby programmer.)

I think that this is the exact same Ruby syntax as you use when defining a full class yourself.

In Python, the equivalent is:

def newfunction(self, ...):
  [whatever]
SomeClass.newfunction = newfunction

This is shorter but less direct, involves more repetition, and doesn't clearly mark the new function as purely a class method (to be really equivalent to the Ruby version we should do 'del newfunction' to clean it out of our namespace). Full-scale lambdas would make this slightly better because then you wouldn't need to define the function separately and then glue it on to the class, but it would still look nothing like the way you define classes themselves.

The limits of monkey patching in Python

One of the things I find interesting is the question of why monkey-patching is a common thing in the Ruby world but not in the Python world. Certainly a significant part of this is cultural (Python culture is very much against monkey patching, Ruby culture seems to be completely accepting of it), but it's hard for me to believe that that's the whole story. People do things to solve problems and I don't believe that Python is magically without the problems that cause people to monkey-patch Ruby. I've recently come up with not so much a theory as an observation on this.

One of the things that people do with Ruby monkey-patching is adding convenience methods to core Ruby classes, things like strings and arrays. You can't do this in Python, because Python monkey-patching has a fundamental limit: you can't monkey-patch anything written in C. Well, you can't monkey-patch it unless it went out of its way to let you, and most modules written in C don't.

There's two aspects of this. To start with, a fair number of the interesting Python classes and modules are written in C, including (of course) all of the fundamental types. These are all de facto sealed from modification and given that Python's culture is against monkey-patching it's unlikely that a proposal to change that would be accepted (to put it one way). This means that you simply can't do a fair amount of the monkey patching that happens in Ruby.

More generally, that C-level things can't be monkey patched makes it at least somewhat dangerous to patch anything that might plausibly be turned into a C module even if it isn't one right now. This is probably especially likely to happen to popular data structures (any number of which have made journeys from Python to C). If such a transition does happen, your monkey patching will immediately fail and you'll have to find another way.

(I don't know if this really acts as a disincentive, though, because I'm not sure that people who might monkey patch such things are aware of this issue.)