[Python-Dev] Monkeypatching idioms -- elegant or ugly?

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:
>
>   * add_method_to_class
>
>   * extend_class

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 monkeypatch_method 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