Well this post comes as a lesson learned the hard way and a warning to fellow programmers in dynamic languages. In a sentence, don't monkey-patch. Seriously, just don't do it.
With the advent of dynamic languages like Python we are treated with very powerful yet dangerous features. Monkey patching, the practice of substituting one unit of functionality with another at runtime is one of those really dangerous things.
It started out simply enough, I wanted some functionality from the standard cgi library in python; so I copied the relevant functions into my code and went about my merry way with everything working well. This felt a little dirty at the time since it violates DRY and I really try to keep my code DRY. Well I tend to write my code first and rough in the documentation then give everything a once-over and touch up documentation and unit tests before I commit it for production use. This is where I tend to get myself in trouble.
Lo and behold, I'm going back over this set of code and realize that I really don't need to copy and paste the code but rather I can just replace one function in the standard library with my customized version. So I did and so began my troubles.
So it bears stepping back and really understanding what was happening here. In Python the real act of importing a module happens only once for the entire life of your program. When the compiler is asked to import a module it will parse it once and after that all you're doing is importing it into your namespace, its already parsed and any module-level variables remain the same for the entire duration of your program. So, lets say for example you import the cgi module in a class deep within your program and decide to monkey-patch it. But, unbeknown to you the application server with which you share a namespace also imports this cgi module and uses it to handle the script environment. Well now everything works just great until your monkey-patch gets executed, then all of a sudden the remainder of your script will use the modified cgi module.
Lets also consider that your application server runs in two modes, for the sake of example; a fastcgi mode where application server processes can linger for hours and a cgi mode where application servers are spawned and killed with each request. Now you've got a seriously sneaky bug on your hands. Your code is going to potentially fail in one environment and run just fine in the other. Oh and now, no matter how much you look at that code you're not going to understand why it's failing until you realize what you've done by monkey-patching something.
This is the story of my day. A hard learned lesson. However, much thanks to my patient co-workers who helped me to see the error of my ways. Head this warning and do not monkey-patch things, your co-workers may not be so kind :-).
Fine print: Ok, so I know there are some legitimate cases for monkey-patching, however I'm learning that those are pretty rare and in general its a dangerous practice in which to engage.