[Python-Dev] Monkeypatching idioms -- elegant or ugly? (original) (raw)
Kevin Teague kevin at bud.ca
Thu Jan 31 06:00:58 CET 2008
- Previous message: [Python-Dev] Assigning issues
- Next message: [Python-Dev] Monkeypatching idioms -- elegant or ugly?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
+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.
I would perhaps call these methods something like:
add_method_to_class
extend_class
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).
- Previous message: [Python-Dev] Assigning issues
- Next message: [Python-Dev] Monkeypatching idioms -- elegant or ugly?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]