On Wed, Jul 18, 2012 at 10:26 AM, Victor Stinner <victor.stin...@gmail.com> wrote: >>> Monkey patching is a common practice in Python. test_os.py replaces >>> os.exec*() functions temporary for example. >> >> Perhaps for testing, but I don't think monkey-patching is common in >> production code. Perhaps you are thinking of Ruby :) > > The gevent library does monkey-patch os.fork (and time.sleep and many > other functions), but gevent is maybe not ready for production? :-)
In many cases, it isn't. Quite often third party libraries require updates to be compatible with gevent's modifications (and if they make a blocking call to an API that gevent doesn't patch, then things really don't work). However, if you don't have third party dependencies that conflict with gevent, then gevent is a brilliant approach to scaling network IO bound applications. Monkey patching needs to be recognised for what it is: a fork of the monkey-patched project. It's a fork that happens at runtime, but it's a fork nonetheless. It comes with all the increased coupling that a fork implies, just without the distribution complexity of trying to have two versions of the monkey-patched project installed at the same time. In this case, it's a *good* thing that monkey-patching will change the answers from the query functions, because we *don't know* if any monkey-patched versions will support the additional arguments (in fact, they probably won't). So, unless the monkey-patching project: 1. Updates their monkey-patched versions to support the additional parameters; and 2. Correctly registers their patched versions in the query sets Then 3.3 will actually give the right answer by assuming that any monkey-patched versions don't support the new parameters. When they *do* support the API additions, then they're easy to register (by adding them to the relevant sets) when putting the monkey-patch in place. Using the functions directly also avoids the classic problem of triggering the fallback path *all* the time by making a typo in the query string (we actually had exactly that problem during the 3.3. development cycle when the initial hasattr() checks in shutil degraded gracefully when the previously separate functions were replaced with the dir_fd keyword argument support). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
