Related
Today when I tried to run simple code on Sublime Text 3, the following message appeared:
Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640
And when I type Python in CMD, it opens the Windows Store for me to download Python 3.7. This problem started today for no good reason. I didn't change or download anything about Python and already tried reinstalling Python, and the Path environment variable is correct.
Use the Windows search bar to find "Manage app execution aliases". There should be two aliases for Python. Unselect them, and this will allow the usual Python aliases "python" and "python3". See the image below.
I think we have this problem when installing Python because in a new Windows installation the aliases are in the ON position as in image below. When turned on, Windows puts an empty or fake file named python.exe and python3.exe in the directory named %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. This is the alias.
Then Microsoft put that directory at the top of the list in the "Path" environment variables.
When you enter "python" in cmd, it searches the directories listed in your "Path" environment variables page from top to bottom. So if you installed Python after a new Windows 10 install then get redirected to the Windows Store, it's because there are two python.exe's: The alias in the App Execution Alias page, and the real one wherever you installed Python. But cmd finds the App execution, alias python.exe, first because that directory is at the top of the Path.
I think the easiest solution is to just check the python.exe and python3.exe to OFF as I suggested before, which deletes the fake EXE file files. Based on this Microsoft Devblog, they stated they created this system partially for new Python users, specifically kids learning Python in school that had trouble installing it.
Creating this alias was to help kids just starting Python to install it and focus on learning to code. I think Windows probably deletes those aliases if you install Python from the Windows App Store. We are noticing that they do not get deleted if you manually install from another source.
(Also, the empty/fake python.exe is not really empty. It says 0 KB in the screenshot, but entering "start ms-windows-store:" in cmd opens the Windows App Store, so it probably just has a line with that and a way to direct it to the Python page.)
Finally, as Chipjust suggested, you can create a new alias for Python using something like DOSKEY as explained in this article for example:
How to set aliases for the command prompt in Windows
The main problem here is that the order in the path calls the windows from top to bottom, and that there is python.exe in %USERPROFILE%\AppData\Local\Microsoft\WindowsApps which is called first if there are no other python.exes in the PATH above that line.
To ensure that the correct python.exe is called, add the Python interpreter installation folder (containing python.exe) to the PATH, above %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
Here is an example:
To get to this location, click "Start" → start typing "Env" → Select "Edit the system environment variables" → "Environment variables" button → Select the entry for "Path" in the upper list → Click "Edit".
Python components should be at the top, as in step 5. If not, move them up by pressing the button in step 6.
If the Python interpreter is already installed, then go to Apps & features from settings, select Python, and then select modify.
Again select modify and select Next:
Then this window will appear:
Select "add Python to environment variable" and click on the install button. Then again go to apps & features, click modify and click Repair.
Now go to CMD and type Python.
Problem solved.
This is a PowerShell script that does the magic.
Remove-Item $env:USERPROFILE\AppData\Local\Microsoft\WindowsApps\python*.exe
I had problems with this as well, where Windows didn't recognize Python or Anaconda in a double click or cmd (command) prompt.
Problem: unable to import libraries in "python" cmd in Windows. Instead the Windows "python" cmd took users somewhere they don't want to go.
Problem Cause: In Windows "Environmental Variables", Windows adds a python.exe and python3.exe (I don't know where these link to) in the "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps" directory.
Solution: I tried deleting the python*.exe files in the WindowsApp directory, but Windows wouldn't allow it, so I opened a command prompt in the "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps" directory and typed:
del python.exe
del python3.exe
Then I created an environment variable linking to the installed Python interpreter link. In my case, it was C:\Anaconda3; C:\Anaconda3\Scripts, and some others for good measure.
Because this is a common issue and this appears to be the canonical question, I want to try to give a complete overview of The Python 3.7 Windows Store Fiasco (TM).
Why is it possible for this to happen?
A convergence of two things: the previous introduction of the Python Launcher for Windows in 2011 (hereafter py), and a Windows 10 update in May 2019 that was apparently intended to make installing Python easier for Windows users.
Oops. Turns out that installation path isn't great; it bypasses the "lengthy" setup wizard... which contains some options that some users find very useful. It caused other issues, too. Not to mention that it just works in slightly non-standard ways, has limitations on file system access because it's a Store app, initially couldn't itself be launched by py....
Okay, but why do those factors result in the problem?
Since the introduction of py, by default, Windows Python installers do not add the new Python install to the PATH. Why? Because the entire point of py is that it uses its own logic to find a Python installation, based on some combination of command-line switches and possibly the source file's own shebang line. Now your source files can be associated with py instead of any particular python.exe, and you can get Linux-like behaviour when double-clicking a file. Meanwhile, by running py at the command line, you have easy access to whatever you need, and you don't have to think about which version of Python was installed most recently. So there's seemingly no good reason to put any of those Python installations on the PATH. It only risks confusing you when, for example, the most recently installed version isn't the most up-to-date one. Right?
In the update, Windows 10 put a "python.exe" into a Windows Apps-related folder, which is a wrapper app to open a Microsoft Store link. The idea is that it's on the PATH, but way near the end; so if you have an installed Python, it gets used, and otherwise the wrapper is invoked and helpfully prompts you to install Python - so that you can actually run that random, totally trusted .py file your friend sent you on Discord.
And it would work perfectly, if your installed Python were on the PATH.
Oops.
(But, you know, py had been introduced around 8 years prior. You'd think someone at Microsoft would have been aware of the potential issue. Maybe instead of a special shortcut link, they could have made an actual script that checks for the presence of C:\Windows\py.exe or something.)
So what are my options?
You can check the option to add new Python versions to the PATH when you install them, and deal with the fact that python at the command line means a specific one of them. If you need to change that, you can manually tweak your PATH variable.
You can just manually tweak the PATH variable after the fact. (or "Modify" a Python installation to fix it.) This is covered in several other answers.
Independently of that, you can disable the wrappers, as shown in the top answer. You should probably do this anyway; seeing python fail at the command line is less aggravating than dealing with a random GUI window popping up and offering to install something for you, especially when you know you have it already.
If you want to keep the PATH empty, consider using virtual environments for your projects. Whenever a virtual environment is active, the PATH is temporarily modified such that python means the Python installation of that environment. It's quite convenient, really.
You might be able to tell your IDEs to use py instead of a specific Python installation, and it might even be helpful to do so. I don't know. I don't use one.
As a person who does Python development in Sublime Text, I know you said the Python interpreter path was correct, but when you install the Python interpreter make sure to tick the option to add Python to PATH.
I had the same issue back in the day till I did this.
You can manually add Python to the Windows path by doing this:
Start the Run box and enter sysdm.cpl
Go to the Advanced tab and click the Environment Variables button
Now you’ll need to locate the relevant Python paths
Here is how a Python application path looks like:
And this is how a Python Scripts path looks like:
Select the Path variable, press edit and add both paths (Python application and Python Scripts)
If it doesn't show, press new instead of edit and fill the New User Variable box
This is how my Variable value looks like:
C:\Users\Ron\AppData\Local\Programs\Python\Python37-32;C:\Users\Ron\AppData\Local\Programs\Python\Python37-32\Scripts
That’s it! You just added Python to the Windows Path.
Source: Data To Fish
So, I had the same problem.
My answer was to add python to PATH not only for User variables, it was there, but also for System variables. And now everything works.
So, I've got the same problem in VENV.
I solved it by typing >> python**.exe**
But to add every time .exe a little bit nervous.
Also try to type python.exe in cmd.
This is an additional note for anyone using pyenv-win: after turning off the application execution aliases, run pyenv rehash. You may also need to close/reopen your CMD or PowerShell window.
I have put together a powershell snippet, which reorders WindowsApps and Python folder so that Python is first. Run this as Admin:
$appsFld="$env:USERPROFILE\AppData\Local\Microsoft\WindowsApps";
$pyPath=(Resolve-Path "$env:USERPROFILE\AppData\Local\Programs\Python\Python*\")
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$appsFld" }) -join ';');
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$pyPath" }) -join ';');
$Env:Path += ";$pyPath";
$Env:Path +=";$appsFld";
[Environment]::SetEnvironmentVariable("PATH", "$Env:Path", "Machine")
Then I can run python just fine:
> python
Python 3.10.7 (tags/v3.10.7:6cc6b13, Sep 5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Adding a bit to the question. Even when I typed pip freeze, it wasn't showing anything.
Here's what I did:
There were multiple instances for the Python application in /AppData/Local/Microsoft/WindowApps.
I deleted those and then it worked.
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.
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
Yes, I've searched. So after spending about 4-5 hours struggling just to get Python files running, I recently stumbled over the solution to get it running through the environment variables like this: cmd -> python -> Python starts, yay yay
Since it didn't work to do it through the command line and similar I had to do it manually through the Windows interface. Now that it's working, however I cannot open .py files without typing out the full path like this: python C:\X\X\X\test.py which is obviously also starting to get annoying.
So now I'm trying to find out which variable I have to change (yet again) to only be able to type 'python test.py' and have it running. Sorry if I come off vague, but it's always a major pain to setup a new programming language for me and it kills my mood.
Thanks for help, it'll be really appreciated.
When you say
able to type 'python test.py'
I'm not sure exactly what you mean. Normally when the Python interpreter runs, it looks in the current directory for any source file that is named on the command line (unless you specifically name a location for the source file, as you've discovered). It seems from your previous statement:
python C:\X\X\X\test.py which is obviously also starting to get annoying
that your test.py file exists somewhere else.
What you might want to try is to change the current directory first, before running your script. In a command prompt window, type:
C:
cd \X\X\X
python test.py
(obviously substituting your actual path name). My apologies if you already know this.
To make python executable on your command line, you need to add it to your PATH environment variable, which it sounds like you have done on the command line. It is quite simple to add directories to the PATH in Windows if you know where to look. Essentially, you need to get to the Environment Variables dialog box, which is slightly different for each version of Windows.
For Windows XP: Start -> Control Panel -> System -> Advanced -> Environment Variables
For Windows Vista, 7: Click the Start Orb, right-click Computer and select Properties -> Advanced -> Environment Variables
Then, in the lower of the two boxes, find Path and click Edit. Change it so that C:\Python27 (or whichever version of Python you have) is at one end of the list, separated from the other entries by a semicolon (e.g. C:\Python27;C:\Program Files ...)
Once you've done this, python will work at the command line whenever you open a command window.
Regarding your second issue, however, there isn't much you can do. You must either specify the complete path to your script or already be in the same directory as the script. That is, if the script is in C:\X\X\X you will either need to invoke it as C:\X\X\X\test.py or first cd C:\X\X\X.
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.