[Python-Dev] Use function names instead of functions for os.supports_dir_fd?

Nick Coghlan ncoghlan at gmail.com
Wed Jul 18 08:50:24 CEST 2012


On Wed, Jul 18, 2012 at 10:26 AM, Victor Stinner
<victor.stinner at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list