title: How to run a Python script portably without specifying its full path
body: <p>Is there a portable way to run a python script from a shell without writing its full path?</p>
  
  <p>For example in Linux, I would like while in my home directory</p>
  
  <pre><code>cd ~
  </code></pre>
  
  <p>to be able to run a python script called run.py that is in say, ~/long/path/to/run.py, but I want to run it by simply typing</p>
  
  <pre><code>python run.py
  </code></pre>
  
  <p>instead of</p>
  
  <pre><code>python ~/long/path/to/run.py
  </code></pre>
  
  <p>I would hope for some kind of search path list that contains several directories just like the PATH variable, so that python run.py runs the first run.py it encounters in one of the directories.</p>
  
  <p>I have considered turning run.py into an executable and adding its directory the system PATH variable, but could not find a portable way of making a python script executable.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>One year later after asking it, I am a bit less noob, and I see that my question was not very clear and did not make much sense, so after a question upvote I'll clarify some things.</p>
  
  <p>1) Portable.</p>
  
  <p>When I asked this I said portable. However what portable means is not clear in this case, and I did not give much emphasis to it.</p>
  
  <ul>
  <li><p>the platforms: should work on POSIX (Linux, MacOS, etc.) and Windows</p></li>
  <li><p>this still does not make much sense since windows uses <code>cmd.exe</code>, and POSIX uses <code>sh</code>, so each one could run the commands with a different syntax. So let's say that the most portable thing possible would be to feed the same input to both <code>sh</code> and <code>cmd.exe</code>, running the python script in both cases. In this case, you could run the same command from an ANSI C <code>system</code> function, which uses <code>sh</code> on POSIX and <code>cmd</code> on Windows. ANSI C being one of the few things that is common to Windows and POSIX, the question makes some sense in that case.</p></li>
  </ul>
  
  <p>2) Executable</p>
  
  <p>Next, the phrase <code>turning run.py into an executable</code>, is not very clear. By that I was talking about the Linux strategy of <code>chmod +x run.py</code>, add a shebang <code>#!/usr/bin/env python</code>, and adding its directory the system add ~/long/path/to/ the PATH enviroment variable. But then this won't work for windows because windows does not support an executable file metadata property like Linux and because /usr/bin/env does not necessarily exist in Windows.</p>
  
  <p>3) Extension</p>
  
  <p>Finally, in my head I was hoping for a solution that does not specify what kind of file run is, so that if someday we decide to make it, say, a perl file, no interfaces would change.</p>
  
  <p>Therefore, writing <code>run.py</code> would be bad because it would specify the filetype; it would be better to be able to write just <code>run</code></p>