IMO, monkey patching is a great convenience for small scripts.
It's a really bad idea for large applications with many 3rd-party
libraries.
You don't have to do monkey patching to use gevent, although
it sounds like you do need to use monkey patching to use
the async module of the requests library, which is a shame.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
I agree do disagree -- very much. :)
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://www.dublinstore.com/
There's a limited number of blocking functions in Python, so monkey-
patching them is easy. In contrast, the callers of those functions are
not under your control, assuming that you even know about all of them
(which you don't).
I'm mildly uncomfortable with monkeypatching myself, but I don't see any
better way, except (as Matt said) modify the stdlib to know about
gevent / greenlets. However, in a way we're already doing exactly
that. ;-)
--
-- Matthias Urlichs
Code that uses the standard library (or other 3rd-party libraries) has
certain expectations about it's semantics. Changing the semantics
behind it's back is a recipe for disaster.
If you have a networking (or any other) library that blocks, and you
don't want to put it in a thread pool, then use some other
library. <shrug>
BTW:
"There's a limited number of blocking functions in Python"
This is incorrect. Reading from a file blocks. Computation
blocks. Lots of things block.
The sweet spot for purely a async architecture is an application (like
half of mine :) that just moves bits between sockets. Anything else,
should be prepared to block (like the other half of mine), which is
why async frameworks are often paired with thread pools.
> Code that uses the standard library (or other 3rd-party libraries) has
> certain expectations about it's semantics. Changing the semantics
> behind it's back is a recipe for disaster.
*its (both times …)
Most if not all libraries which use blocking are perfectly happy to be
used in a thread, though. Which means that, unless with greenlets, a
different thread can pull the rug from under them at any time it damn
well pleases, not just while they happen to block.
So I fail to see any problem with monkeypatching that the "use a thread"
alternate solution would not also have. In spades.
> "There's a limited number of blocking functions in Python"
>
> This is incorrect. Reading from a file blocks. Computation
> blocks. Lots of things block.
True. If that's a problem, then you need to farm out the work to
Something Else.
As far as I am concerned, however, I'd rather use some sort of
multiprocessing. OS threads don't even let you use a second CPU,
due to the GIL.
--
-- Matthias Urlichs
*unlike. Sheesh. ;-)