Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py. http://www.trentm.com/projects/which/ Why which.py? |which.py| is a small GNU-which replacement. It has the following features: * it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and "App Paths" registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note "near misses" on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module. I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib. -- Shane Geiger IT Director National Council on Economic Education sgeiger@ncee.net | 402-438-8958 | http://www.ncee.net Leading the Campaign for Economic and Financial Literacy
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust. (Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.) --Guido On 3/31/07, Shane Geiger <sgeiger@ncee.net> wrote:
Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py.
http://www.trentm.com/projects/which/
Why which.py?
|which.py| is a small GNU-which replacement. It has the following features:
* it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and "App Paths" registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note "near misses" on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module.
I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib.
-- Shane Geiger IT Director National Council on Economic Education sgeiger@ncee.net | 402-438-8958 | http://www.ncee.net
Leading the Campaign for Economic and Financial Literacy
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
on 31.03.2007 22:39 Guido van Rossum said the following:
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust.
Some time ago, I posted a `feature request`_ about which.py including the proposal to put it into the std-lib as ``which`` or ``os.which`` to allow programmatic use and:: python -m which ... This should take care of the visibility problem. ;-) However, there are several todos_, including tests and docs, before this can even be considered. I am afraid I did not have any time to work on it yet. cheers, stefan .. _feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=1509798&group_id=5470&atid=355470 .. _todos: http://trentm.com/projects/which/TODO.txt
(Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.)
--Guido
On 3/31/07, Shane Geiger <sgeiger@ncee.net> wrote:
Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py.
http://www.trentm.com/projects/which/
Why which.py?
|which.py| is a small GNU-which replacement. It has the following features:
* it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and "App Paths" registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note "near misses" on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module.
I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib.
It's out of character for the standard library, since (regardless of whether it's implemented in Python or part of the standard library) it's a stand-alone utility. I don't see much use for this as a library module. On 4/1/07, Stefan Rank <list-ener@strank.info> wrote:
on 31.03.2007 22:39 Guido van Rossum said the following:
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust.
Some time ago, I posted a `feature request`_ about which.py including the proposal to put it into the std-lib as ``which`` or ``os.which`` to allow programmatic use and::
python -m which ...
This should take care of the visibility problem. ;-) However, there are several todos_, including tests and docs, before this can even be considered.
I am afraid I did not have any time to work on it yet.
cheers, stefan
.. _feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=1509798&group_id=5470&atid=355470 .. _todos: http://trentm.com/projects/which/TODO.txt
(Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.)
--Guido
On 3/31/07, Shane Geiger <sgeiger@ncee.net> wrote:
Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py.
http://www.trentm.com/projects/which/
Why which.py?
|which.py| is a small GNU-which replacement. It has the following features:
* it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and "App Paths" registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note "near misses" on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module.
I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
on 01.04.2007 17:23 Guido van Rossum said the following:
It's out of character for the standard library, since (regardless of whether it's implemented in Python or part of the standard library) it's a stand-alone utility. I don't see much use for this as a library module.
I use it as a library, because it encodes knowledge about locating executables on different platforms, especially Windows. Unixoids have which and the search is relatively straightforward. Windows searches paths in PATH and in the registry, and uses PATHEXT, so, for me, the main benefit of which.py is that it provides a which replacement on Windows that takes these quirks into account. A small use case, but a use case nevertheless. I never use which.py as a stand-alone utility as I have cygwin. (But I think it would be helpful when deploying on somebody else's Windows computer.) Of course it is your call if it fits in the stdlib or not. cheers, stefan
Stefan> I use it as a library, because it encodes knowledge about Stefan> locating executables on different platforms, especially Windows. Stefan> Unixoids have which and the search is relatively Stefan> straightforward. Windows searches paths in PATH and in the Stefan> registry, and uses PATHEXT, so, for me, the main benefit of Stefan> which.py is that it provides a which replacement on Windows that Stefan> takes these quirks into account. I'll second that. In SpamBayes we not so long ago added the ability to run OCR software over images to try and identify image-based spam. Needless to say, we had to write fairly different bits of code on Unix v. Windows to locate the gocr or ocrad executables. Having something like a platform-independent which available in Python would have made this aspect of the code easier to write. Skip
Ok, sorry, that *is* a valid use case. Since Trent on his webpage suggests his code as a stdlib replacement I support this now. (But I'm not going to take further action -- I hope you can get one of the regular 2.6 dev guys to adopt this case. Also, the PSF needs to have a contribution form on file from Trent Mick.) --Guido On 4/1/07, Stefan Rank <list-ener@strank.info> wrote:
on 01.04.2007 17:23 Guido van Rossum said the following:
It's out of character for the standard library, since (regardless of whether it's implemented in Python or part of the standard library) it's a stand-alone utility. I don't see much use for this as a library module.
I use it as a library, because it encodes knowledge about locating executables on different platforms, especially Windows. Unixoids have which and the search is relatively straightforward. Windows searches paths in PATH and in the registry, and uses PATHEXT, so, for me, the main benefit of which.py is that it provides a which replacement on Windows that takes these quirks into account.
A small use case, but a use case nevertheless.
I never use which.py as a stand-alone utility as I have cygwin. (But I think it would be helpful when deploying on somebody else's Windows computer.)
Of course it is your call if it fits in the stdlib or not.
cheers, stefan
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust.
(Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.)
Agreed. However, I think my which.py might be a good candidate for the stdlib (for Py2.6) as per python.org/sf/1509798 and could put together a patch (along with test suite integrate and docs) if others think it worthwhile. Trent -- Trent Mick trentm at activestate.com
I think it's worthwhile. On 4/2/07, Trent Mick <trentm@activestate.com> wrote:
Guido van Rossum wrote:
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust.
(Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.)
Agreed. However, I think my which.py might be a good candidate for the stdlib (for Py2.6) as per python.org/sf/1509798 and could put together a patch (along with test suite integrate and docs) if others think it worthwhile.
Trent
-- Trent Mick trentm at activestate.com
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Trent> Agreed. However, I think my which.py might be a good candidate Trent> for the stdlib (for Py2.6) as per python.org/sf/1509798 and could Trent> put together a patch (along with test suite integrate and docs) Trent> if others think it worthwhile. +1. Since I run with 2.6 at home and run SpamBayes from source I can tweak my SpamBayes code to use it as well. I'm now monitoring the above tracker id and will try to massage things once there's a suitable patch uploaded. Skip
participants (6)
-
Greg Ewing -
Guido van Rossum -
Shane Geiger -
skip＠pobox.com -
Stefan Rank -
Trent Mick