To (monkey)patch or not to (monkey)patch, that is the question

Discussion in 'Python' started by George Sakkis, Feb 9, 2010.

  1. I was talking to a colleague about one rather unexpected/undesired
    (though not buggy) behavior of some package we use. Although there is
    an easy fix (or at least workaround) on our end without any apparent
    side effect, he strongly suggested extending the relevant code by hard
    patching it and posting the patch upstream, hopefully to be accepted
    at some point in the future. In fact we maintain patches against
    specific versions of several packages that are applied automatically
    on each new build. The main argument is that this is the right thing
    to do, as opposed to an "ugly" workaround or a fragile monkey patch.
    On the other hand, I favor practicality over purity and my general
    rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
    least for anything less than a (critical) bug fix.

    So I'm wondering if there is a consensus on when it's better to (hard)
    patch, monkey patch or just try to work around a third party package
    that doesn't do exactly what one would like. Does it have mainly to do
    with the reason for the patch (e.g. fixing a bug, modifying behavior,
    adding missing feature), the given package (size, complexity,
    maturity, developer responsiveness), something else or there are no
    general rules and one should decide on a case-by-case basis ?

    George
     
    George Sakkis, Feb 9, 2010
    #1
    1. Advertising

  2. On Feb 9, 12:54 am, George Sakkis <> wrote:
    > So I'm wondering if there is a consensus on when it's better to (hard)
    > patch, monkey patch or just try to work around a third party package
    > that doesn't do exactly what one would like. Does it have mainly to do
    > with the reason for the patch (e.g. fixing a bug, modifying behavior,
    > adding missing feature), the given package (size, complexity,
    > maturity, developer responsiveness), something else or there are no
    > general rules and one should decide on a case-by-case basis ?


    I agree that practically beats purity here. Python is a consenting
    adults language that makes monkey patching possible. It provides
    a direct way to compensate for someone failing to put hooks in
    their API.

    The risk of monkey patching is that if other modules use the patched
    module, they have no way of knowing that the behavior is changed.
    IOW, monkey patching is a fragile technique for a large project.


    Raymond
     
    Raymond Hettinger, Feb 9, 2010
    #2
    1. Advertising

  3. George Sakkis

    Guest

    On Feb 9, 3:54 am, George Sakkis <> wrote:
    > I was talking to a colleague about one rather unexpected/undesired
    > (though not buggy) behavior of some package we use. Although there is
    > an easy fix (or at least workaround) on our end without any apparent
    > side effect, he strongly suggested extending the relevant code by hard
    > patching it and posting the patch upstream, hopefully to be accepted
    > at some point in the future. In fact we maintain patches against
    > specific versions of several packages that are applied automatically
    > on each new build. The main argument is that this is the right thing
    > to do, as opposed to an "ugly" workaround or a fragile monkey patch.
    > On the other hand, I favor practicality over purity and my general
    > rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
    > least for anything less than a (critical) bug fix.


    I'd monkey patch for the meantime, but send a hard patch in the hopes
    of shifting the maintenance burden to someone else. (Plus maybe help
    out the upstream project and other people, I guess)
     
    , Feb 9, 2010
    #3
  4. George Sakkis

    Aahz Guest

    In article <>,
    >

    George Sakkis <> wrote:
    >
    >I was talking to a colleague about one rather unexpected/undesired
    >(though not buggy) behavior of some package we use. Although there is
    >an easy fix (or at least workaround) on our end without any apparent
    >side effect, he strongly suggested extending the relevant code by hard
    >patching it and posting the patch upstream, hopefully to be accepted
    >at some point in the future. In fact we maintain patches against
    >specific versions of several packages that are applied automatically
    >on each new build. The main argument is that this is the right thing
    >to do, as opposed to an "ugly" workaround or a fragile monkey patch.
    >On the other hand, I favor practicality over purity and my general
    >rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
    >least for anything less than a (critical) bug fix.
    >
    >So I'm wondering if there is a consensus on when it's better to (hard)
    >patch, monkey patch or just try to work around a third party package
    >that doesn't do exactly what one would like. Does it have mainly to do
    >with the reason for the patch (e.g. fixing a bug, modifying behavior,
    >adding missing feature), the given package (size, complexity,
    >maturity, developer responsiveness), something else or there are no
    >general rules and one should decide on a case-by-case basis ?


    There's a related option that I chose for SQLObject: extending by using
    internal APIs. Because SQLite doesn't work well with multiple writers
    (or even multiple readers with one writer when queries take a long time),
    we needed a retry mechanism when a query failed. I originally tried
    proxying the SQLite class, but that ran into problems partly related to
    new-style classes grabbing magic methods directly from the class, and
    subclassing and using the internal registration API turned out to be
    easier. The only change required in the existing code was to change the
    connection string to "sqlite_retry:".

    Then I ran into build problems because some machines were on SQLObject
    0.10.x and others were on 0.11.x and the internal API changed between
    those versions. It was easily fixed by upgrading everything to 0.11.x,
    but it's a reminder about the fragility of relying on internal APIs.

    If that's not an option in your case, personally I'd prefer
    monkey-patching because otherwise I need to check the package into my
    repository. Submitting a patch upstream would be responsible behavior.

    Overall, I think that this is definitely an issue where heuristics work
    much better than rules.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "At Resolver we've found it useful to short-circuit any doubt and just
    refer to comments in code as 'lies'. :)"
     
    Aahz, Feb 14, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Brueck

    OT: There's a monkey on my keyboard,

    Dave Brueck, Jan 9, 2004, in forum: Python
    Replies:
    0
    Views:
    302
    Dave Brueck
    Jan 9, 2004
  2. Shugo Maeda

    A bug of the monkey patch for REXML

    Shugo Maeda, Nov 8, 2008, in forum: Ruby
    Replies:
    0
    Views:
    88
    Shugo Maeda
    Nov 8, 2008
  3. Alfredo Mesen

    Help with FasterCSV monkey patch

    Alfredo Mesen, Jan 21, 2009, in forum: Ruby
    Replies:
    3
    Views:
    99
    James Gray
    Jan 22, 2009
  4. MaggotChild
    Replies:
    14
    Views:
    202
    MaggotChild
    Sep 23, 2009
  5. Marc Aymerich

    Is it possible monkey patch like this?

    Marc Aymerich, Dec 18, 2012, in forum: Python
    Replies:
    4
    Views:
    147
    Steven D'Aprano
    Dec 19, 2012
Loading...

Share This Page