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.

Jul 20, 2014 Monkey Patching in python. But if the change is very small then the faster method will be to monkey patch that function or module. Sometimes, a monkey patch is a necessary evil. This package makes it easier to apply a monkey patch during Zope startup. Audition Dance Battle Philippines For. It uses the ZCML configuration machinery to.

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? Stephen Hansen IMHO, monkey-patching is one of those things that you shouldn't really mention in the public without looking both ways, leaning in, and lowering your voice. Its not that its -bad- exactly, and its really not terribly kinky or obscene, but its something that you still shouldn't exactly do in polite company, y'know? There's no guarantees it'll work forever, so its not the safest practice, but if you're willing to accept the burden (and ideally have a unit test proving that it still functions. On Tue, Feb 9, 2010 at 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?IMHO, monkey-patching is one of those things that you shouldn't really mention in the public without looking both ways, leaning in, and lowering your voice.

Its not that its -bad- exactly, and its really not terribly kinky or obscene, but its something that you still shouldn't exactly do in polite company, y'know? There's no guarantees it'll work forever, so its not the safest practice, but if you're willing to accept the burden (and ideally have a unit test proving that it still functions after an update to such a package), then. Consenting adults! If you can get the upstream package to make such a thing not necessary, that's ideal-er, of course. 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.