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 <[EMAIL PROTECTED]> wrote: > On Jan 30, 2008 9:00 PM, Kevin Teague <[EMAIL PROTECTED]> 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/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nate%40binkert.org > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
