[Python-Dev] Monkeypatching idioms -- elegant or ugly? (original) (raw)

Guido van Rossum guido at python.org
Thu Jan 31 18:23:26 CET 2008

On Jan 30, 2008 9:00 PM, Kevin Teague <kevin at bud.ca> wrote:

+1 on having established Python idioms for these techniques.

While I don't know if there has ever been a formal definition of monkey patch, the term monkey patch came from guerilla patch, which came from two or more dynamic modifications to a class interfering with each other. These modifications were usually made by extension code (Zope add-on Products) to upstream code (the Zope framework), so I would define a monkey patch only as dynamic modifications made to a class with the intent to change or correct behaviour in upstream code. The term has also caught on with the a second definition of referring to any dynamic modification of class, regardless of intent though.

Check out the wikipedia entry too.

I would perhaps call these methods something like:

* addmethodtoclass * extendclass

I don't like extend because in Java that's how you define a subclass.

This gives you a better idea of what they do, rather than use a term with a somewhat ambigous definition. With monkeypatchmethod under the definition of "altering existing upstream behviour", I might expect it to raise an error if the method I was replacing on a class did not exist (e.g. upstream code was refactored so my patch no longer applied).

Funny, several examples mentioned earlier in this thread actually check that the method doesn't already exist...

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list