homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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

AltStyle によって変換されたページ (->オリジナル) /