Author edemaine
Recipients
Date 2001-07-25.20:13:53
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
I would like to propose a small addition to the
standard Python distribution.  I had in mind two
additional functions for the os module, but where they
fit is subject to debate.  They are:

 1. which (command[, path]): Finds executable files
with the given
    name in the standard operating system path
(os.environ['PATH'])
    or the user-specified path (which can be a string
using the
    os.pathsep separator, or a Python list of
directories in which to
    search).

    Availability: UNIX and Windows, at least.  I don't
know enough
    about the relevant details of Mac to know whether
this is
    relevant.  The attached implementation uses
os.access, which
    is only available on UNIX and Windows.

Rationale: It is often useful to check for the
existence of a
particular program.  os.system and os.execp use or
mimic the
search-in-path functionality, but are often unsuitable
for this
purpose, because they require running the program right
now.
Suppose you want to see what's appropriate -- fsh (fast
version
of ssh), ssh, or rsh (ick) -- and use that decision
later on?
In the particular case I have in mind, I want to be
able to
configure my script to say that the sound_player is
either
esd if there is an executable program with that name in
the
path, or else none.  With which, I can say

    if which ('esd'):
        sound_player = 'esd'  # or which ('esd') [0]
    else:
        sound_player = None

Another common use (for me at least) would be for
scripts that
replace other programs in path, but still need to run
the
programs they replace.  (E.g., I have a script called
'ssh' that
resets an xterm's title once the real 'ssh' completes.)
This could be done as follows:

    def find_alternate (program, not_this):
        for alt in which (program):
            if not os.path.samefile (alt, not_this):
return alt
        return None / raise ...

Counterargument: which is a one-liner
(see the attached implementation)

Response: In my opinion, it is a longish one-liner, and
is only
obvious to people who know functional programming (map,
reduce, and filter).  And in my opinion it is a
sufficiently
common scripting operation that it warrents a helper
function.
It is of course a minor feature, but os is filled with
many,
very helpful, helper routines, and I think this is a
similarly
useful one.  (But this is of course subject to
argument.)

I made a small inquiry on irc.openprojects.net:#debian
about
whether this sounded useful, and two people voted yes,
and no one voted no.

Since the functionality of which is closely matched by
os.access,
I further propose that which can be specified a
different mode than
"executable file" by an optional argument.  That is
included in the
attached implementation.

 2. find_in_path (command[, path]): Finds all
files/directories with the
    given name in the standard operating system path
    or the user-specified path (specified as in which).

    Availability: Everywhere (using os.path.exists
instead of os.access)

Rationale: This is a natural generalization of which;
indeed, which
is seen most naturally as a filter of the result of
this function.
In fact, that is how I implemented which in the
attached
implementation.

More relevantly, this function allows you to find the
font with a
given name in your font directory, to find the
appropriate TeX file
in os.environ['TEXINPUTS'], etc., etc.

Similar counterpoint/response for this function.  Again
I think this is
a sufficiently common operation to warrent a help
function.

You are also very welcome to propose a different name
than
find_in_path.

Feel free to post comments for or against this
proposal.
History
Date User Action Args
2007-08-23 16:01:14adminlinkissue444582 messages
2007-08-23 16:01:14admincreate