We Keep Coding

Running a Python script with and without "python" [duplicate]

I have a simple script blah.py (using Python 2):
import sys
print sys.argv[1]
If I execute my script by:
python c:/..../blah.py argument
It prints argument but if I execute script by:
blah.py argument
error occurs:
IndexError...
So arguments do not pass to script.
python.exe in PATH. Folder with blah.py also in PATH.
python.exe is default program to execute *.py files.
What is the problem?

When you execute a script without typing "python" in front, you need to know two things about how Windows invokes the program. First is to find out what kind of file Windows thinks it is:
C:\>assoc .py
.py=Python.File
Next, you need to know how Windows is executing things with that extension. It's associated with the file type "Python.File", so this command shows what it will be doing:
C:\>ftype Python.File
Python.File="c:\python26\python.exe" "%1" %*
So on my machine, when I type "blah.py foo", it will execute this exact command, with no difference in results than if I had typed the full thing myself:
"c:\python26\python.exe" "blah.py" foo
If you type the same thing, including the quotation marks, then you'll get results identical to when you just type "blah.py foo". Now you're in a position to figure out the rest of your problem for yourself.
(Or post more helpful information in your question, like actual cut-and-paste copies of what you see in the console. Note that people who do that type of thing get their questions voted up, and they get reputation points, and more people are likely to help them with good answers.)
Brought In From Comments:
Even if assoc and ftype display the correct information, it may happen that the arguments are stripped off. What may help in that case is directly fixing the relevant registry keys for Python. Set the
HKEY_CLASSES_ROOT\Applications\python26.exe\shell\open\command
key to:
"C:\Python26\python26.exe" "%1" %*
Likely, previously, %* was missing. Similarly, set
HKEY_CLASSES_ROOT\py_auto_file\shell\open\command
to the same value. See http://eli.thegreenplace.net/2010/12/14/problem-passing-arguments-to-python-scripts-on-windows/
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command The registry path may vary, use python26.exe or python.exe or whichever is already in the registry.
HKEY_CLASSES_ROOT\py_auto_file\shell\open\command

you should make the default application to handle python files be python.exe.
right click a *.py file, select "Open With" dialog. In there select "python.exe" and check "always use this program for this file type" (something like that).
then your python files will always be run using python.exe

Additionally, if you want to be able to run your python scripts without typing the .py (or .pyw) on the end of the file name, you need to add .PY (or .PY;.PYW) to the list of extensions in the PATHEXT environment variable.
In Windows 7:
right-click on Computer
left-click Properties
left-click Advanced system settings
left-click the Advanced tab
left-click Environment Variables...
under "system variables" scroll down until you see PATHEXT
left-click on PATHEXT to highlight it
left-click Edit...
Edit "Variable value" so that it contains ;.PY (the End key will skip to the end)
left-click OK
left-click OK
left-click OK
Note #1: command-prompt windows won't see the change w/o being closed and reopened.
Note #2: the difference between the .py and .pyw extensions is that the former opens a command prompt when run, and the latter doesn't.
On my computer, I added ;.PY;.PYW as the last (lowest-priority) extensions, so the "before" and "after" values of PATHEXT were:
before: .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
after .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
Here are some instructive commands:
C:\>echo %pathext%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
C:\>assoc .py
.py=Python.File
C:\>ftype Python.File
Python.File="C:\Python32\python.exe" "%1" %*
C:\>assoc .pyw
.pyw=Python.NoConFile
C:\>ftype Python.NoConFile
Python.NoConFile="C:\Python32\pythonw.exe" "%1" %*
C:\>type c:\windows\helloworld.py
print("Hello, world!") # always use a comma for direct address
C:\>helloworld
Hello, world!
C:\>

How to execute Python scripts in Windows?
You could install pylauncher. It is used to launch .py, .pyw, .pyc, .pyo files and supports multiple Python installations:
T\:> blah.py argument
You can run your Python script without specifying .py extension if you have .py, .pyw in PATHEXT environment variable:
T:\> blah argument
It adds support for shebang (#! header line) to select desired Python version on Windows if you have multiple versions installed. You could use *nix-compatible syntax #! /usr/bin/env python.
You can specify version explicitly e.g., to run using the latest installed Python 3 version:
T:\> py -3 blah.py argument
It should also fix your sys.argv issue as a side-effect.

I encountered the same problem but in the context of needing to package my code for Windows users (coming from Linux).
My package contains a number of scripts with command line options.
I need these scripts to get installed in the appropriate location on Windows users' machines so that they can invoke them from the command line.
As the package is supposedly user-friendly, asking my users to change their registry to run these scripts would be impossible.
I came across a solution that the folks at Continuum use for Python scripts that come with their Anaconda package -- check out your Anaconda/Scripts directory for examples.
For a Python script test, create two files: a test.bat and a test-script.py.
test.bat looks as follows (the .bat files in Anaconda\Scripts call python.exe with a relative path which I adapted for my purposes):
#echo off
set PYFILE=%~f0
set PYFILE=%PYFILE:~0,-4%-script.py
"python.exe" "%PYFILE%" %*
test-script.py is your actual Python script:
import sys
print sys.argv
If you leave these two files in your local directory you can invoke your Python script through the .bat file by doing
test.bat hello world
['C:\\...\\test-scripy.py', 'hello', 'world']
If you copy both files to a location that is on your PATH (such as Anaconda\Scripts) then you can even invoke your script by leaving out the .bat suffix
test hello world
['C:\\...Anaconda\\Scripts\\test-scripy.py', 'hello', 'world']
Disclaimer: I have no idea what's going on and how this works and so would appreciate any explanation.

On Windows,
To run a python module without typing "python",
--> Right click any python(*.py) file
--> Set the open with property to "python.exe"
--> Check the "always use this program for this file type"
--> Append the path of python.exe to variable environment e.g. append
C:\Python27 to PATH environment variable.
To Run a python module without typing ".py" extension
--> Edit PATHEXT system variable and append ".PY" extension to the list.

Can you execute python.exe from any map?
If you do not, chek if you have proper values for python.exe in PATH enviroment
Are you in same directory than blah.py. Check this by issuing command -> edit blah.py and check if you can open this file
EDIT:
In that case you can not. (python arg means that you call python.exe whit some parameters which python assume that is filename of script you want to run)
You can create bat file whit lines in your path map and run .bat file
Example:
In one of Path maps create blah.py.bat
Edit file and put line
python C:\Somedir\blah.py
You can now run blah.py from anywere, becuase you do not need to put .bat extention when running bat files

Found an incredibly useful answer here: How to run different python versions in cmd?
I would suggest using the Python Launcher for Windows utility that introduced was into Python 3.3 a while ago. You can also manually download and install it directly from the author's website for use with earlier versions of Python 2 and 3.
Regardless of how you obtain it, after installation it will have associated itself with all the standard Python file extensions (i.e. .py, .pyw, .pyc, and .pyo files). You'll not only be able to explicitly control which version is used at the command-prompt, but also on a script-by-script basis by adding Linux/Unix-y shebang #!/usr/bin/env pythonX comments at the beginning of your Python scripts.
As J.F. Sebastian suggests, Python Launcher for Windows is the best and default choice for launching different version of Python in Windows. It used to be a third-party tool, but now it is officially supported since Python 3.3.
New in version 3.3.
The Python launcher for Windows is a utility which aids in the location and execution of different Python versions. It allows scripts (or the command-line) to indicate a preference for a specific Python version, and will locate and execute that version.
This is a great tool just use it!

Simply run the command:
C:>python .\file_name.py
Assuming the file name is within same folder and Python has already been added to environment variables.

create an application in excel using python for a user without python

I am doing an application in Excel and I'd like to use python language. I've seen a pretty cool library called xlwings, but to run it a user need to have python installed.
Is there any possibility to prepare this kind of application that will be launch from a PC without Python?
Any suggestion are welcome!

A small workaround could be to package your application with cx_freeze or pyinstaller. Then it can run on a machine without installing python. The downside is of course that the program tend to be a bit bulky in size.

no. you must need install a python and for interpreting the python function etc.

It is possible using xlloop. This is a customized client-server approach, where the client is an excel .xll which must be installed on client's machine.
The server can be written in many languages, including python, and of course it must be launched on a server that has python installed. Currently the .xll is available only for 32 bits.

This might not be exactly what you're looking for (i.e.- "without python"), but you could ship it as a virtualenv .zip folder with all the necessary packages and respective python installation included in the folder... and also include a run.command bash executable inside the folder that the user can click on to run your program. You'll have to tell the user (inside a README.txt or something) how to enable the executable... For a particular application mine looked like...
Please complete the following steps after installation of MyApplication.zip:
Step 1: Move the MyApplication folder to your Desktop.
Step 2: Open your Terminal in Go then Applications then Utilities.
Step 3: In the Terminal, paste cd ~/Desktop/MyApplication
then press Enter.
Step 4: Then, paste chmod +x run.command
then press Enter.
From now on, clicking the “run” file in MyApplication will run the application.
If clicking the “run” file still doesn’t work, then do…
Click Ok on the popup then Open System Preferences then Security & Privacy
then Click on Open Anyway button then Click Open button on the popup.
NOTE: Please do not move or delete the MyApplication folder, or any of its files.
Then my run.command executable looked like the following:
cd ~/Desktop/MyApplication
PATH=$PATH:$HOME/Desktop/MyApplication/lib/python2.7/site-packages:$HOME/Desktop/MyApplication/lib/python2.7/site-packages/aeosa:$HOME/Desktop/MyApplication/lib/python2.7/lib-dynload:$HOME/Desktop/MyApplication/lib/python2.7/lib-old:$HOME/Desktop/MyApplication/lib/python2.7/lib-tk:$HOME/Desktop/MyApplication/Extras/lib/python:$HOME/Desktop/MyApplication/lib/python2.7/plat-mac/lib-scriptpackages:$HOME/Desktop/MyApplication/lib/python2.7/plat-mac:$HOME/Desktop/MyApplication/lib/python2.7/plat-darwin:$HOME/Desktop/MyApplication/lib/python2.7:$HOME/Desktop/MyApplication/lib/python27.zip
source bin/activate
python main.py
Three things are important here:
1) In run.command, I first change directory into the virtualenv I created for this project. I'm not trying to be dynamic here, since this is all just a quick hack of a solution, so as part of the README.txt, I simply tell the user to put the folder they downloaded onto their desktop. Otherwise, the cd command wouldn't work.
2) I set the client's PATH variable, separating entries with colons. You can see a list of the paths you'd need using a quick check on your computer...
import sys
for path in sys.path:
print path
3) I then call source bin/activate to activate the virtualenv.
4) I then execute my main.py file, which is in the top level of my virtualenv, along with run.command.
5) I only wrote this bash file for Mac OS X, so I don't know how it would translate to windows PCs. I think the only thing that'd change is that the path literals would need to use backslashes instead of forward slashes, but again, I haven't done this for windows so I'm uncertain.
Read more about setting up a virtualenv here: https://virtualenv.readthedocs.org/en/latest/index.html
Finally, note that you will not be able to send your final, working .zip folder over most email services, since they tend to prevent people from sending executables back and forth, so you'll have to use a service like Dropbox or something to send it to people.

When using Python Windows Launcher, is there any way to prevent having to type full path?

In Windows 8, I often use the Python Windows Launcher like
py C:/long/long/long/long/long/path/to/prog.py ...
Is there any way to set some environment setting, such as PATH or PYTHONPATH etc, to prevent having to type the full path to prog.py?
From my basic knowledge/research, PATH only helps with the py part of the command line and PYTHONPATH only helps with imports within prog.py, so how do I deal with the path to prog.py itself??
Notes:
I cannot modify the code, not even the "shebang" line, since it is needed to work on other platforms.
I cannot cd to the directory containing the programs to run them, because the programs will do something based on the directory they're run in (they'll modify the files in the directory they're run in).
I know that if I associate .py extension with the Python Windows Launcher, then I can run prog.py as the first item in the command line, and thus use PATH, but currently my .py extension is associated with my favorite editor and I'd like to keep it that way if possible (so I can double-click any Python file in Windows Explorer and edit it).
However, if someone suggests a solution where I can have a different association for Windows Explorer versus the command line, then that could be a potential solution! (i.e. in Windows Explorer, .py opens with the editor, while on command line, .py runs with Python Windows Launcher)

Add your long path to PYTHONPATH, then invoke your program as such:
python -m prog
Python will search for a module called prog and then run it as the main module.

Answer to my own question: Actually, I'm so silly. I could just set a variable for each program path (there are only a few programs paths), i.e.. prog=C:/long/path/to/prog.py and then do py %prog% .... I guess I figured out an answer to my own question that was acceptable to me.
Update: I just found something even better. I can do
doskey prog=py C:/long/path/to/prog.py $*
and then simply prog ... afterward
Now I just have to do some crazy stuff to get the doskey command into a file that will be run every time I start a console, as described here: https://stackoverflow.com/a/21040825/5182136

How to execute Python scripts in Windows?

I have a simple script blah.py (using Python 2):
import sys
print sys.argv[1]
If I execute my script by:
python c:/..../blah.py argument
It prints argument but if I execute script by:
blah.py argument
error occurs:
IndexError...
So arguments do not pass to script.
python.exe in PATH. Folder with blah.py also in PATH.
python.exe is default program to execute *.py files.
What is the problem?

When you execute a script without typing "python" in front, you need to know two things about how Windows invokes the program. First is to find out what kind of file Windows thinks it is:
C:\>assoc .py
.py=Python.File
Next, you need to know how Windows is executing things with that extension. It's associated with the file type "Python.File", so this command shows what it will be doing:
C:\>ftype Python.File
Python.File="c:\python26\python.exe" "%1" %*
So on my machine, when I type "blah.py foo", it will execute this exact command, with no difference in results than if I had typed the full thing myself:
"c:\python26\python.exe" "blah.py" foo
If you type the same thing, including the quotation marks, then you'll get results identical to when you just type "blah.py foo". Now you're in a position to figure out the rest of your problem for yourself.
(Or post more helpful information in your question, like actual cut-and-paste copies of what you see in the console. Note that people who do that type of thing get their questions voted up, and they get reputation points, and more people are likely to help them with good answers.)
Brought In From Comments:
Even if assoc and ftype display the correct information, it may happen that the arguments are stripped off. What may help in that case is directly fixing the relevant registry keys for Python. Set the
HKEY_CLASSES_ROOT\Applications\python26.exe\shell\open\command
key to:
"C:\Python26\python26.exe" "%1" %*
Likely, previously, %* was missing. Similarly, set
HKEY_CLASSES_ROOT\py_auto_file\shell\open\command
to the same value. See http://eli.thegreenplace.net/2010/12/14/problem-passing-arguments-to-python-scripts-on-windows/
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command The registry path may vary, use python26.exe or python.exe or whichever is already in the registry.
HKEY_CLASSES_ROOT\py_auto_file\shell\open\command

you should make the default application to handle python files be python.exe.
right click a *.py file, select "Open With" dialog. In there select "python.exe" and check "always use this program for this file type" (something like that).
then your python files will always be run using python.exe

Additionally, if you want to be able to run your python scripts without typing the .py (or .pyw) on the end of the file name, you need to add .PY (or .PY;.PYW) to the list of extensions in the PATHEXT environment variable.
In Windows 7:
right-click on Computer
left-click Properties
left-click Advanced system settings
left-click the Advanced tab
left-click Environment Variables...
under "system variables" scroll down until you see PATHEXT
left-click on PATHEXT to highlight it
left-click Edit...
Edit "Variable value" so that it contains ;.PY (the End key will skip to the end)
left-click OK
left-click OK
left-click OK
Note #1: command-prompt windows won't see the change w/o being closed and reopened.
Note #2: the difference between the .py and .pyw extensions is that the former opens a command prompt when run, and the latter doesn't.
On my computer, I added ;.PY;.PYW as the last (lowest-priority) extensions, so the "before" and "after" values of PATHEXT were:
before: .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
after .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
Here are some instructive commands:
C:\>echo %pathext%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
C:\>assoc .py
.py=Python.File
C:\>ftype Python.File
Python.File="C:\Python32\python.exe" "%1" %*
C:\>assoc .pyw
.pyw=Python.NoConFile
C:\>ftype Python.NoConFile
Python.NoConFile="C:\Python32\pythonw.exe" "%1" %*
C:\>type c:\windows\helloworld.py
print("Hello, world!") # always use a comma for direct address
C:\>helloworld
Hello, world!
C:\>

How to execute Python scripts in Windows?
You could install pylauncher. It is used to launch .py, .pyw, .pyc, .pyo files and supports multiple Python installations:
T\:> blah.py argument
You can run your Python script without specifying .py extension if you have .py, .pyw in PATHEXT environment variable:
T:\> blah argument
It adds support for shebang (#! header line) to select desired Python version on Windows if you have multiple versions installed. You could use *nix-compatible syntax #! /usr/bin/env python.
You can specify version explicitly e.g., to run using the latest installed Python 3 version:
T:\> py -3 blah.py argument
It should also fix your sys.argv issue as a side-effect.

I encountered the same problem but in the context of needing to package my code for Windows users (coming from Linux).
My package contains a number of scripts with command line options.
I need these scripts to get installed in the appropriate location on Windows users' machines so that they can invoke them from the command line.
As the package is supposedly user-friendly, asking my users to change their registry to run these scripts would be impossible.
I came across a solution that the folks at Continuum use for Python scripts that come with their Anaconda package -- check out your Anaconda/Scripts directory for examples.
For a Python script test, create two files: a test.bat and a test-script.py.
test.bat looks as follows (the .bat files in Anaconda\Scripts call python.exe with a relative path which I adapted for my purposes):
#echo off
set PYFILE=%~f0
set PYFILE=%PYFILE:~0,-4%-script.py
"python.exe" "%PYFILE%" %*
test-script.py is your actual Python script:
import sys
print sys.argv
If you leave these two files in your local directory you can invoke your Python script through the .bat file by doing
test.bat hello world
['C:\\...\\test-scripy.py', 'hello', 'world']
If you copy both files to a location that is on your PATH (such as Anaconda\Scripts) then you can even invoke your script by leaving out the .bat suffix
test hello world
['C:\\...Anaconda\\Scripts\\test-scripy.py', 'hello', 'world']
Disclaimer: I have no idea what's going on and how this works and so would appreciate any explanation.

On Windows,
To run a python module without typing "python",
--> Right click any python(*.py) file
--> Set the open with property to "python.exe"
--> Check the "always use this program for this file type"
--> Append the path of python.exe to variable environment e.g. append
C:\Python27 to PATH environment variable.
To Run a python module without typing ".py" extension
--> Edit PATHEXT system variable and append ".PY" extension to the list.

Can you execute python.exe from any map?
If you do not, chek if you have proper values for python.exe in PATH enviroment
Are you in same directory than blah.py. Check this by issuing command -> edit blah.py and check if you can open this file
EDIT:
In that case you can not. (python arg means that you call python.exe whit some parameters which python assume that is filename of script you want to run)
You can create bat file whit lines in your path map and run .bat file
Example:
In one of Path maps create blah.py.bat
Edit file and put line
python C:\Somedir\blah.py
You can now run blah.py from anywere, becuase you do not need to put .bat extention when running bat files

Found an incredibly useful answer here: How to run different python versions in cmd?
I would suggest using the Python Launcher for Windows utility that introduced was into Python 3.3 a while ago. You can also manually download and install it directly from the author's website for use with earlier versions of Python 2 and 3.
Regardless of how you obtain it, after installation it will have associated itself with all the standard Python file extensions (i.e. .py, .pyw, .pyc, and .pyo files). You'll not only be able to explicitly control which version is used at the command-prompt, but also on a script-by-script basis by adding Linux/Unix-y shebang #!/usr/bin/env pythonX comments at the beginning of your Python scripts.
As J.F. Sebastian suggests, Python Launcher for Windows is the best and default choice for launching different version of Python in Windows. It used to be a third-party tool, but now it is officially supported since Python 3.3.
New in version 3.3.
The Python launcher for Windows is a utility which aids in the location and execution of different Python versions. It allows scripts (or the command-line) to indicate a preference for a specific Python version, and will locate and execute that version.
This is a great tool just use it!

Simply run the command:
C:>python .\file_name.py
Assuming the file name is within same folder and Python has already been added to environment variables.

Compile a .pyw file so it can be run like .pyc without console

I'm trying to compile a pyw file into a pyc without console. When I try a straight compile with it, the result is a pywc file, but it seems that pythonw.exe doesn't register that extension as one of it's files like python.exe does for a pyc.
The result of course is that it has no double click handler when you try to just execute, or if you change the extension to pyc, you get the console.
Does anybody know a way around this issue? Something to the affect of a .pyc with no console?
Thanks!
Update:
Since running this through execfile or by double clicking on the icon in windows soesn't generate a compiled version of this file, I start python in command line, then :
import py_compile
py_compile.compile("[FileName].pyw")
This is where I get the .pywc extension from.
My Python version is 2.5.4

(following a little discussion in the OP's post)
If what you need is provide clients or users with the compiled application in form of *.pyc or *.pyo, and avoid opening the console at the execution, a good option is to leave a *.pyw wrapper that calls the main application.
Let's assume the main application is in main.pyc, and the entry point main, and let's call the wrapper top.pyw, which would typically look like:
# top.pyw file
import main
if __name__ == "__main__":
import sys
main.main(*sys.argv[1:])
Your main.py file would then look like this:
# main.py file
"""
Main module documentation (optional)
"""
# import modules
# function and class definitions
def main(*argv):
# Parses the options (optional)
import optparse
parser = optparse.OptionParser(usage="%prog [<options>]\n" + __doc__)
parser.add_option(...)
parser.add_option(...)
opt, args = parser.parse_args(list(argv))
# Calls the appropriate function:
my_function(...)
Note also that *.pyc tend to be version-specific. You can check whether the solution above would be compatible with pyInstaller and similar "independent" distribution methods.
Edit => In fact, if you use pyInstaller, you can simply include all your scripts and produce an executable which will be independent of the Python installation, and starts with no console (-w option when you create the specs). You don't even need to use a wrapper or change your extensions. While it will be a larger file, that could be what you were looking for.
Finally, just in case that's where you are headed: if you don't want someone else to extract source code from the compiled bytecode, don't forget that you will need additional precautions. This is called code obfuscation and there are other threads on SO about that (for example this one). Don't hesitate to post a new question if you only come up with old answers on that one, those things can change fast.

The interpreter that reads .pyw files is also capable of reading a python compiled .pyc formatted file. Simply rename your .pyc file to .pyw. It will run (although it will still be version specific), and you won't get the ugly console.

You can use the FTYPE and ASSOC commands to associate .pywc files with pythonw.exe.
ASSOC is used to associate an extension with a file type, and FTYPE associates a file type with the command used to open it. The following commands show existing assocations on my machine:
C:\Python26>assoc .py
.py=Python.File
C:\Python26>assoc .pyc
.pyc=Python.CompiledFile
C:\Python26>assoc .pyw
.pyw=Python.NoConFile
C:\Python26>assoc .pywc
File association not found for extension .pywc
These commands show what programs the extensions are associated with through their file types:
C:\Python26>ftype Python.CompiledFile
Python.CompiledFile="C:\Python26\python.exe" "%1" %*
C:\Python26>ftype Python.NoConFile
Python.NoConFile="C:\Python26\pythonw.exe" "%1" %*
So it looks like you could just associate .pywc files with Python.NoConFile like this:
assoc .pywc=Python.NoConFile

Just rename the [fileName].pywc to [fileName].pyw and open it. It works it did for me. Also the code is not visible when you try to open it for editing it opens like an exe file in notepad.