views:

1119

answers:

8

In many discussions I have heard about Ruby in which people have expressed their reservations about the language, the issue of monkey patching comes up as one of their primary concerns.

However, I rarely hear the same arguments made in the context of Python although it is also permitted in the Python language.

Why this distinction?

Does Python include different types of safeguards to minimize the risks of this feature?

+10  A: 

The languages might permit it, but neither community condones the practice. Monkeypatching isn't condoned in either language, but you hear about it more often in Ruby because the form of open class it uses makes it very, very easy to monkeypatch a class and because of this, it's more acceptable in the Ruby community, but still frowned upon. Monkeypatching simply isn't as prevalent or as easy in Python, which is why you won't hear the same arguments against it in that community. Python does nothing that Ruby doesn't do to prevent the practice.

The reason you hear/read about it more often in Ruby is that this in Ruby:

class MyClass
  def foo
    puts "foo"
  end
end

class MyClass
  def bar
    puts "bar"
  end
end

Will give you a class that contains two methods, foo and bar, whereas this in Python:

class MyClass:
    def foo():
        print "foo"

class MyClass:
    def bar():
        print "bar"

Will leave you with a class that only contains the method bar as redefinition of a class clobbers the previous definition completely. That alone makes Ruby code much easier to monkeypatch than Python code.

Keith Gaughan
Your Python example is valid, too. The second definition just creates a new MyClass-class and does not extend the previous one (I guess thats what ruby does).
unbeknown
You should add a note that it's technically valid
hasen j
Can you provide some reference that shows the Ruby "community" not condoning the practice? What about ActiveSupport::CoreExtensions?
Mike Woodhouse
@hasen j: I think my latest edits should be enough. @Mike Woodhouse: Have done. I'm not saying there wasn't a laissez-faire attitude towards it in the past, but there's been a seachange towards its restrained use in the past year or two. Anyway, is Rails a fair example of Ruby? Its code's a mess!
Keith Gaughan
You can easily get the same effect in Python. Remove the second "class MyClass" line and put "MyClass.bar = bar" at the end after bar is defined. Also, you forgot the self argument for your class functions.
Adam K. Johnson
@Adam: No, you see, that's misses the point of what I'm demonstrating. Dropping the second class declaration would leave you with a single class declaration; a Python class declaration creates a new class object, where as Ruby ones extends existing ones. Also, self wasn't needed for the example.
Keith Gaughan
+11  A: 

"Does Python include different types of safeguards to minimize the risks of this feature?"

Yes. The community refuses to do it. The safeguard is entirely social.

S.Lott
+18  A: 

It's a technique less practised in Python, in part because "core" classes in Python (those implemented in C) are not really modifiable. In Ruby, on the other hand, because of the way it's implemented internally (not better, just different) just about anything can be modified dynamically.

Philosophically, it's something that tends to be frowned on within the Python community, distinctly less so in the Ruby world. I don't know why you assert that it's more controversial (can you link to an authoritative reference?) - my experience has been that monkey-patching is an accepted technique if one where the user should be aware of possible consequences.

Mike Woodhouse
I can't speak about the Ruby community so I'll take your word that monkeypatching is accepted there, but if you walk into a room full of Python developers and ask them what they think of Ruby, you are more likely than not to hear the term "monkey patching" come up, and not in a positive light.
Paul Dexter
Yes, but 'controversial among Python programmers' is different than 'controverial among Rub programmers'. While it's possible to do monkey-patching in Python (and recognized as sometimes useful but dangerous), there are a number of language features of Ruby that seem to actively encourage it.
Jeff Shannon
(argh, that should be 'controversial among Ruby programmers' above, of course...)
Jeff Shannon
@Paul Dexter: I just see that difference as a consequence of the languages being different and some subset of the practitioners of both being ignorant of the strengths and weaknesses of the other. I use and like both languages but prefer Ruby, in part because of its (to me) broader OO capabilities.
Mike Woodhouse
+2  A: 

Actually in Python it's a bit harder to modify basic types.

For example imagine, that you redefine integer.

Ruby:

class Fixnum 
   def *(n)
      5 
   end 
end

Now 2*2 yields 5.

Python:

>>> class int(int):
    def __mul__(self, x):
     return 5


>>> 2*2
4
>>> int(2)*int(2)
5
vartec
That Ruby example doesn't do what you think. That would make it so you'd do Integer.times {|five| "The number is one less than #{five + 1}"} and it would return 6. 2*2, however, would still be 4. You want class Fixnum; def *(n); 5; end; end .
Chuck
@Chuck: thanks, I really haven't got much experience with Ruby (yet), I'm a Python guy ;-)
vartec
+9  A: 

As a Python programmer who has had a taste of Ruby (and likes it), I think there is somewhat of an ironic parallel to when Python was beginning to become popular.

C and Java programmers would 'bash' Python, stating that it wasn't a real language, and that the dynamic nature of its types would be dangerous, and allow people to create 'bad' code. As python became more popular, and the advantages of its rapid development time became apparent, not to mention the less verbose syntax:

// Java
Person p = new Person();

# Python
p = Person()

we began to see some more dynamic features appear in later versions of Java. Autoboxing and -unboxing make it less troublesome to deal with primitives, and Generics allow us to code once and apply it to many types.

It was with some amusement that I saw one of the key flexible features of Ruby - Monkey Patching, being touted as dangerous by the Python crowd. Having started teaching Ruby to students this year, being able to 'fix' the implementation of an existing class, even one that is part of the system is very powerful.

Sure, you can screw up badly and your program can crash. I can segfault in C pretty easily, too. And Java apps can die flaming death.

The truth is, I see Monkey Patching as the next step in dynamic and meta-programming. Funny, since it has been around since Smalltalk.

Matthew Schinckel
I have heard the term "duck-punching" used in the same vein as "monkey-patching". It is a bit of a play on "duck typing" (if it quacks like a duck, then it may as well be a duck, even if it is an integer). If it doesn't quack like a duck, then you punch it until it does (add new methods, etc).
Matthew Schinckel
+3  A: 

In python, any literal ("",{}, 1.0, etc) creates an instance of the standard class, even if you tried to monkeypatch it and redefined the corresponding class in your namespace.

It just won't work how you intended:

class str():
    # define your custom string type
    ...

a = "foo"      # still a real python string
a = str("foo") # only this uses your custom class
Algorias
+1  A: 

I think that monkey patching should only be used as the last solution.

Normally Python programmers know how a class or a method behave. They know that class xxx is doing things in a certain way.

When you monkey patch a class or a method, you are changing it's behavior. Other Python programmers using this class can be very surprised if that class is behaving differently.

The normal way of doing things is subclassing. That way, other programmers know that they are using a different object. They can use the original class or the subclass if they choose to.

Oli
+1  A: 

If you want to do some monkey patching in Python, it is relatively easy, as long as you are not modifying a built-in type (int, float, str).

class SomeClass:
    def foo(self):
        print "foo"

def tempfunc(self):
    print "bar"
SomeClass.bar = tempfunc
del tempfunc

This will add the bar method to SomeClass and even existing instances of that class can use that injected method.

Adam K. Johnson
Also not-monkey-patchable: datetime.datetime, datetime.timedelta, and many, many more. Shame, as there are ways I want to extend these classes often.
Matthew Schinckel