To (monkey)patch or not to (monkey)patch, that is the question
apt.shansen at gmail.com
Tue Feb 9 16:47:35 CET 2010
On Tue, Feb 9, 2010 at 12:54 AM, George Sakkis <george.sakkis at gmail.com>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
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
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! Go ahead.
If you can get the upstream package to make such a thing not necessary,
that's ideal-er, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list