Thanks everyone! I found the -m method to work best for me, as it allows me to execute a script from anywhere, using multiple Python installs on my machine (I need to do this because I sometimes have to run a script with the python install included with my company's software release). Also, I noticed that creating a package using __init__.py is not necessary to run the script in module mode with -m, but it does have the helpful side effect of forcing me to organize my scripts into meaningful packages, and teaching me about package organization in general.
Thanks again, James On Tue, Apr 12, 2011 at 10:56 AM, Brian Dorsey <[email protected]> wrote: > This is my favorite way to do it on windows: > > currentDir> script.py arg1 arg2 > (don't need to call python at all) > > Make a directory to put all of your scripts in. C:\bin as an example > (although it should be in your user dir). > > Then modify two environment variables: > Add ;c:\bin to PATH > Add ;.py to PATHEXT > > Modifying PATH adds that directory to the paths windows will search > for 'binaries' to execute. Modifying PATHEXT will add .py files to the > list of extensions that windows considers to be executable. This > assumes that .py files are associated with python.exe (the default), > not a text editor. > > This also has the benefit that you can leave #! lines intact and > they'll be ignored on windows and used on other platforms. On the > other hand, if your goal really is to be cross-platform, and you don't > have to share your scripts with other windows people, it might make > more sense to just run bash on your Windows machine. > > There are some slightly bizarre corner cases with this method... but > it's worth it for convenience scripts > - the number of args which can be passed to the script is artificially > limited (I forgot the number... about nine, I think). python.exe > script.py style execution doesn't have this problem. > - the value of sys.argv[0] is different than if you had used > python.exe script.py > > Take care, > -Brian > > On Fri, Apr 8, 2011 at 2:02 PM, James Fort <[email protected]> wrote: > > Hello SeaPIG, > > > > > > > > I wonder if anyone knows how to address the following issue. I looked in > a > > book and Googled for a while and couldn't find what I'm looking for. > > > > > > > > I want to have a directory or set of directories that contain Python > scripts > > which I can execute from anywhere in my file system. Right now, I'm > > concerned with Windows XP, but I may want to do the same in Mac OSX and > > Linux in the future. Essentially, I want to by able to type: > > > > > > > > currentDir>>>python script.py arg1 arg2 > > > > > > > > Where arg1 and arg2 might be files in the current directory that act as > > inputs to the script and script.py is a script that resides in another > > directory. > > > > > > > > Here are some ideas I considered: > > > > > > > > Setting the PYTHONPATH variable to include a directory where script.py is > > stored. This did not work. It seems to only work for importing modules > > once the Python interpreter is already invoked. > > I read online and in a book that you can set "#!/usr/bin/python" as the > > first line in a script, assuming that this is the full path to the > > interpreter, put the script in /usr/bin or any other directory to which > PATH > > points, and run the script using ">>>script.py". I read that this is > only > > an option in Unix, however, and it doesn't allow me to specify the > version > > of Python I want to use as would be possible if I prefixed the script > > submission command with ">>>python26 script.py". This also precludes me > > from using ">>>run script.py" from within Ipython. > > > > > > > > Does anyone know how to handle this? I noticed that I run the same > script > > by copying the script into the directories in which I want to run it, but > > when I make revisions to the script, I have different versions sitting in > > different directories, which is becoming very difficult to manage. > > > > > > > > Thanks, > > > > James >
