Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > To (monkey)patch or not to (monkey)patch, that is the question

Reply
Thread Tools

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

 
 
George Sakkis
Guest
Posts: n/a
 
      02-09-2010
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
 
Reply With Quote
 
 
 
 
Raymond Hettinger
Guest
Posts: n/a
 
      02-09-2010
On Feb 9, 12:54*am, George Sakkis <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
 
sjdevnull@yahoo.com
Guest
Posts: n/a
 
      02-09-2010
On Feb 9, 3:54*am, George Sakkis <(E-Mail Removed)> 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)
 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      02-14-2010
In article <(E-Mail Removed)>,
>

George Sakkis <(E-Mail Removed)> 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 ((E-Mail Removed)) <*> 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'. "
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Why not 'foo = not f' instead of 'foo = (not f or 1) and 0'? Kristian Domke Python 11 01-23-2008 07:27 PM
'' is not a valid name. Make sure that it does not include invalid characters or punctuation and that it is not too long. rote ASP .Net 2 01-23-2008 03:07 PM
Cisco 3640 3620 3600 not detecting, not enabling, not working: NM-2FE2W Taki Soho Cisco 0 09-22-2004 07:28 AM
maintaining control with cookies (not strictly an ASP or even server side question. But not not either) Stephanie Stowe ASP General 2 04-07-2004 04:23 PM



Advertisments