Monkeypatching idioms -- elegant or ugly?
+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).
On Jan 30, 2008 9:00 PM, Kevin Teague <kevin@bud.ca> wrote:
Check out the wikipedia entry too.
I don't like extend because in Java that's how you define a subclass.
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/)
Another thing about monkeypatching is that it seems like the best way to write an extension class where you want half to be in C/C++ and half in Python. I'm in the middle of working on such a class and there are plenty of members that just don't need to be in C++. Is there a better/preferred idiom for such a thing? I don't want to subclass my new class because I want any objects created on the C++ side to also get the python methods. Nate On Jan 31, 2008 9:23 AM, Guido van Rossum <guido@python.org> wrote:
On Jan 31, 2008 9:49 AM, nathan binkert <nate@binkert.org> wrote:
Have you tried this? I believe it doesn't even work; types defined in C++ are supposed to be immutable. Try adding a new method to list or dict. However the C++ side should be able to create instances of the Python-defined subclass as long as it runs in a method, since it has a reference to the actual class. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I am putting PyObject_Head at the front of my class, but only initializing it if it is passed to python. I had intended to initialize the python bits with a C++ type, but I guess I could do it with a cached module lookup of the python derived type. Allocation is really tricky too, so this all may just not be worth the hassle. :) Anyway, if these types of issues are inappropriate for this forum, I'll keep quiet.
On Jan 30, 2008 9:00 PM, Kevin Teague <kevin@bud.ca> wrote:
Check out the wikipedia entry too.
I don't like extend because in Java that's how you define a subclass.
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/)
Another thing about monkeypatching is that it seems like the best way to write an extension class where you want half to be in C/C++ and half in Python. I'm in the middle of working on such a class and there are plenty of members that just don't need to be in C++. Is there a better/preferred idiom for such a thing? I don't want to subclass my new class because I want any objects created on the C++ side to also get the python methods. Nate On Jan 31, 2008 9:23 AM, Guido van Rossum <guido@python.org> wrote:
On Jan 31, 2008 9:49 AM, nathan binkert <nate@binkert.org> wrote:
Have you tried this? I believe it doesn't even work; types defined in C++ are supposed to be immutable. Try adding a new method to list or dict. However the C++ side should be able to create instances of the Python-defined subclass as long as it runs in a method, since it has a reference to the actual class. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I am putting PyObject_Head at the front of my class, but only initializing it if it is passed to python. I had intended to initialize the python bits with a C++ type, but I guess I could do it with a cached module lookup of the python derived type. Allocation is really tricky too, so this all may just not be worth the hassle. :) Anyway, if these types of issues are inappropriate for this forum, I'll keep quiet.
participants (3)
-
Guido van Rossum -
Kevin Teague -
nathan binkert