

Show HN: zodiac, a new approach to monkey patching in python - colinmarc
https://github.com/colinmarc/zodiac

======
davvid
On a related note, Michael Foord's `mock.py` was recently added to the python
stdlib.

<http://www.voidspace.org.uk/python/mock/mock.html>

------
yyyt
I can't see how this is different from mock.py. Mock can also do temporary
patching:

with patch('path.to.object') as my_mock: my_mock.method.return_value = ...

also you can patch a module/class with a function.

------
halayli
I'd avoid monkey patching, it can confuse the programmer as to which module is
being used. In a small program it's not a big deal but in large systems it can
become an issue.

~~~
colinmarc
It makes sense in certain situations. For example, if you're using non-
blocking i/o with an event loop (using gevent or similar) then as soon as you
have one blocking operation, performance suffers dramatically.

Monkeypatching gevent's socket globally allows you to use libraries and
drivers like pymongo off the shelf, and they will be non-blocking by default.

~~~
jrockway
While true, this can hardly be considered good engineering. The more
complexity in your system, the more likely it is to break. The question is: do
you want to take the productivity hit today and fix the socket libraries, or
do you want to fix it at some time in the future when you finally realize your
code/test/release cycle is twice as slow as your competitors'?

(I've worked on a lot of code that took the second trade-off. The result is
almost always a full rewrite. Maintain your codebase or it goes out of control
really fast.)

~~~
colinmarc
I agree that before monkeypatching, a team should weigh their options. But for
many projects, "fixing the socket libraries" could be a lot of work, or not an
option at all.

In the example I gave, you'd have to rewrite whatever database drivers you're
using, or at least hack them to work in a non-blocking fashion. That could
have just as much development cost as monkeypatching.

zodiac is an attempt to address the problems that make monkeypatching such a
risky, unpredictable option, by making patches smaller and therefore using
more system code. Hopefully, for situations where monkeypatching is necessary,
I can make it cleaner and more maintainable.

------
devy
Can we say this is very un-pythonic?

