<html>

 <head>

  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

 </head>

 <body bgcolor="#FFFFFF" text="#330033">

  On 7/20/2011 8:22 PM, Nick Coghlan wrote:

  <blockquote

cite="mid:CADiSq7fCQO-Geg1pqbHcZhDoSXDOTvFkvMQ6VjHJ-faueicCig@mail.gmail.com"

   type="cite">

   <pre wrap="">On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray <a class="moz-txt-link-rfc2396E" href="mailto:rdmurray@bitdance.com">&lt;rdmurray@bitdance.com&gt;</a> wrote:

</pre>

   <blockquote type="cite">

    <pre wrap="">Indeed. If I want to run a script with a different python version

on a unix-like system, I need to know the path to said script.

We're trying to make python as easy to use on Windows as it is on Unix.

If find-script-on-path is considered a worthwhile feature, then as Mark

said it should be added to base Python (on all platforms), not special-cased

in the Windows launcher.

</pre>

   </blockquote>

   <pre wrap="">

And given the diverse range of what Python considers to be an

executable script these days, -1000 to that particular feature. Use

`which scriptname`, that's what it's for. The lack of such

functionality in the underpowered cmd shell on Windows isn't Python's

problem to solve - ask MS for a better shell and command line

utilities (assuming Powershell doesn't already offer something

comparable to 'which').

There are reasons I only code specifically for Windows if someone pays

me to do so :P

</pre>

  </blockquote>

  <br>

  Interesting feedback. Well, I have a "which" program on my machine,

  but as a 32-bit executable, it won't find py in the 64-bit

  c:\windows\system32 directory! Another good reason to demand pay

  for Windows programming. There are some interesting gotchas to the

  way 32- vs 64-bit "compatibility" is achieved in Windows (groan). 

  I'll find or write a better one, in due time. Meantime, the

  launcher testing has been a good learning exercise for me.<br>

  <br>

  Interesting, David, that you feel it that Python usability on

  Windows should be limited to its usability on Unix, rather than to

  exceed it. I don't see that as a necessary or appropriate limit. 

  Windows and Unix are different. Unix people are accustomed to using

  tools like which, and using command lines, and path manipulations;

  Windows people are not. So the use of the command line is already

  somewhat foreign to them, and limiting the launcher so that they

  have to use other command line tools to get the work done, would

  only serve to frustrate them. Now the argument can possibly be made

  that people that want to use launcher from the command line would be

  those that are already command line experts might be realistic, but

  I will note that Perl has a -S option to find its script on the

  PATH, not that that is a sufficient reason to add such to Python, or

  even to the launcher, but just to note that there are at least some

  people besides myself that might think that is a friendly idea.<br>

  <br>

  My goal in writing software is to make it easy to use, regardless of

  whether some other system should be the responsible party or not --

  especially when I don't control the other system. But then, I

  haven't found time to write a competing launcher, either, with

  friendlier features. So, I'll just reiterate that I would find it

  friendly if the launcher searched the path to find the script, and

  agree that if Python had a feature to do so, that would also be

  friendly to the Windows platform, but less necessary on Unix where

  you can `which script.py` (although that would still require more

  typing than if the path searching were automatic.<br>

 </body>

</html>