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

[Raymond Hettinger]

On Feb 9, 12:54 am, George Sakkis <george.sak... 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 ?

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