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

[nathan binkert]

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 at python.org> wrote:
> 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/)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/nate%40binkert.org
>
>