Develop Reference

Unable to change Python 2.7 to Python 3.8 on Sublime and VS code

I have been trying to change my python interpreter on sublime text and VS code and no matter what I do, both of them refuse to change. It always picks the default Python 2.7 version.
On sublime, I tried to create a new build tool, added the path to Python3 but nothing is working.
And on, VS code, even if I select Python3 from the drop-down menu, it doesn't change anything.

I changed the system's default python interpreter from 2.7 to 3.9 and set the path on bash profile. It fixed the issue for me.

I don't know about Sublime, but for VS Code, there looks to be quite a few things to verify:
Check your User Settings on whether you've set up a default interpreter for your applications
Are you using Window 10 WSL? Then you might want to check out issue 3227 for vscode-remote-release where the comment was:
So I was having this same exact issue until I read this article on a wsl tutorial. In there it says we should have "Remote - WSL" extension installed (already did). In the bottom left corner "Remote - WSL" installs a status button that has the "greater than" and "less than" symbols displayed. If you click that button and tell VSCode to open up in the remote WSL distro environment it fixed my issue where vscode was unable to find an interpreter for python.

For Sublime, you need to hit ⌘B with your script pane focused in order to use your new python3.sublime-build build system.
It looks like you are running your script within Terminus, which is fine, but you need to use the python3 command when running it from the command line, even if that command line is within Sublime.
Please check out my answer here on how to make a Python build system that accepts user input, as the Sublime "console" doesn't allow you to interact with your program. Since you already have Terminus installed, I'd recommend going down to the bottom of the answer and using the Terminus build system. That way, you won't have to deal with Terminal windows opening every time you run a build.

The terminal window uses your PATH, not the IDE settings, so manually typing out python --version isn't testing anything except the PATH variable
In order for the terminal to use the "correct" python binary you've specified, it would need to give the absolute path to it, which I believe using Command+B (using the build options) in Sublime would do. Similarly, you can use the Run/Debug Configurations in VSCode.
Or you can modify your ~/.zshrc to fix your PATH, for example installing pyenv to change the entire system Python version, or the one for the current folder

Django manage.py [duplicate]

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.

tput: terminal attributes: No such device or address in Windows Pycharm debugger

I am getting a red message every time I use the console from the debugger and try to see the output of a pandas object
"tput: terminal attributes: No such device or address"
I am using PyCharm 2016.3.2 and according to me I didn't update anything - it just started to appear all of a sudden. I attach a screenshot of the debugger with info on my ipython and debugger versions. Would appreciate your help to understand how to get rid of this message. It seems to appear both in the Python Console and Debugger Console, but not in the PyCharm Terminal. Thanks.

There is a workaround inside PyCharm itself without affecting the rest of the system:
You can hard code PATH as part of Environment set up under this menu:
Click menu Run -> Edit/Configurations...
when the configuration window opens, click on Defaults -> Python.
On the right side under Environment Variables hard code PATH without git/cygwin. See below how to get that path from cmd prompt
import os, re; print ';'.join([p for p in os.getenv('PATH').split(';')
if not re.search('Git', p)])
This PATH variable seems to overwrite system's path variable.
Image of these steps overlaid in PyCharm.

Another workaround is to simply move tput to a different cygwin PATH directory,
e.g. if tput is in ~/git-for-windows/usr/bin, and the same directory is in the windows PATH, moving tput.exe to ~/git-for-windows/usr/local/bin will fix the issue in pycharm and still work within cygwin

Have you installed git or cygwin recently? If so, try to delete git or cygwin related paths from system environment variable PATH. If had the same problem as you and now have fixed it by doing so.

Just to complement the answer from H.J. Liu, if you are unable to delete cygwin from the system PATH, then it is probably in the user PATH. Please see this related post Unable to remove cygwin from PATH environment variable

additional for Anaconda2 Users, you will find tput.exe in following two path:
Anaconda2\Library\usr\bin
Anaconda2\pkgs\git-xxx\Library\usr\bin
mv them to xxx\usr\local\bin

My colleague had the same error. It occurred only for pandas.
We resolved it by changing the project interpreter in PyCharm to the anaconda one, where he previously set up everything else. If for example, you use Anaconda navigator, then all the tput paths are set up there. (Maybe the settings got lost when downloading a new PyCharm version.)
I'm sharing this to give people some more ideas where to look for, not to get too focussed on cygwin.

Impossible to set python.exe to *.py scripts on Win7

i've installed py 2.7 (64bit) on my PC with Win7 (64bit) without problem but I'm not able to run *.py scripts via DOS shell without declare python full path.
Let me better explain :
If I type D:\ myscript.py it doesn't work. The script is open with wordpad
If I type D:\ C:\Python27 myscript.py it works and run correctly
I try to change the default application software for *.py file via Win7 GUI ( control pannel etc etc) but without success.
Python is not present in the list of available sw and in any case also with the manual set I'm not able to associate python.exe at *.py files.
I've checked in my environment variables but I've not found problem (python path is declared in Path = C:\Python27\;C:\Python27\Scripts).
I've tried also to modify HKEY_CLASSES_ROOT->Applications->python.exe->shell->open->command :
old register value "C:\Python27\python.exe" "%1"
new register value "C:\Python27\python.exe" "%1" %*
without success.
Any suggestion?
Thanks

Here is another check to make, which helped me figure out what was going on.
I switched from the 32bit Anaconda to the 64bit version. I deinstalled, downloaded then reinstalled, but several things didn't get cleaned up properly (quick launch stuff, and some registry keys). The problem on my side was that the default installation path changed, from C:\Anaconda to C:\Anaconda2.
I first tried the assoc and ftype tricks, everything was fine there. However, the HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command registry key was pointing to the old Anaconda path. As soon as I fixed this, python.exe showed up when I tried associating with "Open with" and everything went back to normal.
I also added the %* at the end in the registry key.

You could try to use the ASSOCIATE command in CMD:
ASSOCIATE .py C:\PathTo\python.exe
More information at http://ss64.com/nt/associate.html

#slv 's answer is good and helped me a bit with solving this problem. Anyhow, since I had previous installations of Python before this error occured for me, I might have to add something to this. One of the main problems hereby was that the directory of my python-installation changed.
So, I opened regedit.exe and followed these to steps:
I searched the entire registry for .py, .pyw, .pyx and .pyc (hopefully I did not forget to mention any here). Then, I radically deleted all occurrences I could find.
I searched the entire registry for my old python-installation-path (e.g. C:\Users\Desktop\Anaconda3). Then I replaced this path with my new installation path (e.g. C:\Users\Desktop\Miniconda3). Thereby, I also came across and replaced HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command which #slv mentioned.
Afterwards, it was possible again to connect a .py-file from the Open with...-menu with my python.exe.

The *.py file is a source code file. If you set up your system environment correctly, you need to run python myscript.py
the following answer is related to your question
Making Python scripts run on Windows without specifying ".py" extension

Do you know that when you change the default application of a file, you are able to browse for the application?
You can click on the "browse" button (as shown in the red rectangle), then choose C:\Python27\python.exe.
Also remember to click on the "Always use this program to open this program" checkbox, which is shown in the green rectangle, so that win7 knows how to open this file the next time you ask it to open *.py file.
Then I believe you'll be able to run myScript.py simply by typing "myScript.py" in the correct dirctory in DOS shell.
After doing all the above steps, be sure to reopen a new command shell.

"python" not recognized as a command

I just downloaded and installed Python 2.7.2 to my laptop and I am trying to run some sample programs. My laptop is running Windows XP.
When I open a cmd window and type python I get:
'python' is not recognized as an internal or external command, operable program or batch file.
I am not a Windows person (mostly mainframes). However I am guessing that there is some command that I need to execute to define python as a command. Can anyone tell me what that command is?
The installer placed Python at C:\Python27\.

You need to add the python executable path to your Window's PATH variable.
From the desktop, right-click My Computer and click Properties.
In the System Properties window, click on the Advanced tab.
In the Advanced section, click the Environment Variables button.
Highlight the Path variable in the Systems Variable section and click the Edit
button.
Add the path of your python executable(c:\Python27\). Each different directory is separated with a
semicolon. (Note: do not put spaces between elements in the PATH. Your addition to the PATH should read ;c:\Python27 NOT ; C\Python27)
Apply the changes. You might need to restart your system, though simply restarting cmd.exe should be sufficient.
Launch cmd and try again. It should work.

This is because the Python exec are not in the search path of your operating system. In windows, start CMD. Type in
setx PATH PythonPath
where PythonPath is usually C:\Python27 or C:\Python33 or C:\Users\<Your User Name>\AppData\Local\Programs\Python\Python37 depending on your Python version. After restarting the CMD, you should get see outcomes when typing
Python --version

Python comes with a small utility that fixes this. From the command line run:
c:\python27\tools\scripts\win_add2path.py
Make sure you close the command window (with exit or the close button) and open it again.

Just another clarification for those starting out. When you add C:\PythonXX to your path, make sure there are NO SPACES between variables e.g.
This:
SomeOtherDirectory;C:\Python27
Not this:
SomeOtherDirectory; C:\Python27
That took me a good 15 minutes of headache to figure out (I'm on windows 7, might be OS dependent). Happy coding.

I had the same problem for a long time.
I just managed to resolve it.
So, you need to select your Path, like the others said above.
What I did:
Open a command window. Write set path=C:\Python24 (put the location and the version for your python). Now type python, It should work.
The annoying part with this is that you have to type it every time you open the CMD.
I tried to do the permanent one (with the changes in the Environmental variables) but for me its not working.

You can do it in python installer:

Go to Control Panel / System / "Advanced" tab / Enviromental Variables
Find variable called PATH in the lower list, and edit it. Add to the end C:\Python27
Open a new cmd window and try now.

emphasis: Remember to always RESTART the CMD WINDOW after setting the PATH environmental variable for it to take effect!

in PowerShell enter this:
[Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\Python27",
"User")
Close PowerShell and then start it again to make sure Python now runs. If it doesn’t,
restart may be required.

Further to #Udi post this is what the script tried to do, but did not work with me.
I had to the set the following in the PATH nothing else.
C:\Users\hUTBER\AppData\Local\Programs\Python\Python35
C:\Users\hUTBER\AppData\Local\Programs\Python\Python35\Scripts
Were mine and now python works in the cmd

Easy. Won't need to get confused but paths and variables and what to click. Just follow my steps:
Go to the python installer.
Run it.
Out of the 3 options choose modify.
Check py launcher.
Next.
Check "Add python to environment variables"
Install.
Restart the cmd when finished and boom done

If you are trying to install python version python-3.9.6 then click the checkbox of Add Python 3.9 to PATH

Make sure you click on Add python.exe to path during install, and select:
"Will be installed on local hard drive"
It fixed my problem, hope it helps...

Another helpful but simple solution might be restarting your computer after doing the download if Python is in the PATH variable. This has been a mistake I usually make when downloading Python onto a new machine.
After restarting my machine then Windows will often recognize Python in the PATH variable.