<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#330033">
    On 7/20/2011 5:34 PM, Mark Hammond wrote:
    <blockquote cite="mid:4E27741A.1040202@gmail.com" type="cite">On
      21/07/2011 10:13 AM, Glenn Linderman wrote:
      <br>
      <blockquote type="cite" style="color: #000000;">On 7/20/2011 2:43
        PM, Glenn Linderman wrote:
        <br>
        <blockquote type="cite" style="color: #000000;">
          <blockquote type="cite" style="color: #000000;">It's not py's
            job to walk the path: the shell does that when you just type
            <br>
            "foo". It locates foo.py, and then invokes py because of
            file association - py
            <br>
            then checks the file for a shebang to decide which Python to
            dispatch it to.
            <br>
          </blockquote>
          <br>
          Certainly when the launcher is invoked via an association,
          this would
          <br>
          be the case.  However, when the launcher is invoked via the
          command
          <br>
          line, then the unqualified name is passed through.  To be
          useful from
          <br>
          the command line, the launcher should walk the PATH to find
          the .py file.
          <br>
        </blockquote>
        <br>
        The Windows SearchPath API
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx">&lt;http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx&gt;</a>
        <br>
        makes it a pretty easy job to walk the PATH.  Would even allow
        low cost
        <br>
        additional feature of searching for both   foo and foo.py  at
        the same time.
        <br>
      </blockquote>
      <br>
      But that would also require us to parse the command-line,
      understand which options require 2 args and which just require 1
      (making it fragile in the face of later versions introducing new
      options), then re-stitching a modified command-line back together
      for the child process.  IMO that is all out of scope.
      <br>
    </blockquote>
    <br>
    Yes it would be more work.<br>
    <br>
    <blockquote cite="mid:4E27741A.1040202@gmail.com" type="cite">
      <br>
      Are you maybe forgetting about the PATHEXT functionality?  If you
      include .py in your PATHEXT and file associations are set so .py
      files are handled by the launcher, you should be able to directly
      execute just 'foo' and have the command processor search the PATH
      for a foo.py and invoke it via the launcher.</blockquote>
    <br>
    Not at all.  I was just testing the use of the launcher from the
    command line, and seeing the cumbersomeness of using it as a prefix
    to a command that would work on its own, but fails when launched by
    the launcher from the command line.  And the SearchPath API has a
    limited form of PATHEXT support built in, which is what I was trying
    to point out above.  Yes, the use of the launcher via file
    associations can be friendly because it leverages Windows features,
    but its use from the command line presently seems rather unfriendly,
    because it leverages Windows misfeatures.<br>
    <blockquote cite="mid:4E27741A.1040202@gmail.com" type="cite">
      <br>
      <br>
      Mark
    </blockquote>
    <br>
  </body>
</html>