+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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4