今天,当我试图在Sublime Text 3上运行简单的代码时,出现了以下消息:
未找到Python,但可以从Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640安装
当我在CMD中输入Python时,它会打开Windows商店,让我下载Python 3.7。这个问题今天就开始了,没有什么好理由。我没有更改或下载任何关于Python的内容,并且已经尝试重新安装Python,并且Path环境变量是正确的。
今天,当我试图在Sublime Text 3上运行简单的代码时,出现了以下消息:
未找到Python,但可以从Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640安装
当我在CMD中输入Python时,它会打开Windows商店,让我下载Python 3.7。这个问题今天就开始了,没有什么好理由。我没有更改或下载任何关于Python的内容,并且已经尝试重新安装Python,并且Path环境变量是正确的。
当前回答
这里的主要问题是路径中的顺序从上到下调用windows,如果没有其他python,则在%USERPROFILE%\AppData\Local\Microsoft\WindowsApps中首先调用python.exe。在该行上方的PATH中。
为了确保调用正确的Python .exe,将Python解释器安装文件夹(包含Python .exe)添加到PATH中,位于%USERPROFILE%\AppData\Local\Microsoft\WindowsApps之上
这里有一个例子:
点击“开始”→开始输入“Env”→选择“编辑系统环境变量”→“环境变量”按钮→在上方列表中选择“路径”条目→点击“编辑”。
Python组件应该位于顶部,如步骤5所示。如果没有,按下第6步中的按钮向上移动。
其他回答
我把一个powershell片段放在一起,它重新排序了WindowsApps和Python文件夹,所以Python是第一个。以管理员身份运行:
$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")
然后我可以很好地运行python:
> 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
因为这是一个常见的问题,这似乎是一个典型的问题,我想尝试对Python 3.7 Windows Store惨败(TM)进行一个完整的概述。
为什么会发生这种情况?
两件事的融合:2011年为Windows推出的Python启动器(以下简称py),以及2019年5月的Windows 10更新,显然是为了让Windows用户更容易安装Python。
哦。事实证明,安装路径并不好;它绕过了“冗长的”安装向导…其中包含一些用户认为非常有用的选项。这也引发了其他问题。更不用说它只是以稍微非标准的方式工作,对文件系统访问有限制,因为它是一个商店应用程序,最初不能由py....启动
好吧,但是为什么这些因素会导致问题呢?
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?
在更新中,Windows 10将“python.exe”放入Windows应用程序相关文件夹,这是一个用于打开微软商店链接的包装应用程序。我们的想法是,它在PATH上,但接近结尾;所以如果你安装了Python,它就会被使用,否则包装器就会被调用,并帮助你安装Python——这样你就可以运行你朋友在Discord上发给你的那个随机的、完全信任的。py文件。
如果你安装的Python在PATH上,它会完美地工作。
哦。
(但是,你知道,py在8年前就已经被引入了。你可能会认为微软的某个人已经意识到了这个潜在的问题。也许他们可以做一个真正的脚本来检查是否存在C:\Windows\py.exe之类的,而不是一个特殊的快捷链接。)
那么我有什么选择呢?
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.
使用Windows搜索栏找到“管理应用程序执行别名”。Python应该有两个别名。取消选择它们,这将允许使用常见的Python别名“Python”和“python3”。请看下图。
我认为我们在安装Python时遇到了这个问题,因为在新的Windows安装中,别名处于ON位置,如下图所示。打开后,Windows会在%USERPROFILE%\AppData\Local\Microsoft\WindowsApps目录下放置一个名为python.exe和python3.exe的空文件或假文件。这是别名。
然后,Microsoft将该目录放在“Path”环境变量列表的顶部。
当你在cmd中输入“python”时,它会从上到下搜索“Path”环境变量页面中列出的目录。因此,如果你在新的Windows 10安装后安装了Python,然后被重定向到Windows商店,这是因为有两个Python. exe:应用程序执行别名页面中的别名,以及你安装Python的地方的真实别名。但是cmd首先会找到应用程序的执行,别名python.exe,因为该目录位于路径的顶部。
我认为最简单的解决方案是将python.exe和python3.exe检查为OFF,就像我之前建议的那样,这会删除假的EXE文件文件。根据微软的开发博客,他们表示他们创建这个系统的部分目的是为了新的Python用户,特别是在学校学习Python的孩子,他们在安装它时遇到了麻烦。
创建这个别名是为了帮助刚开始学习Python的孩子安装它,并专注于学习编码。我认为如果你从Windows应用商店安装Python, Windows可能会删除这些别名。我们注意到,如果从其他来源手动安装,它们不会被删除。
(另外,空的/fake python.exe并不是真的空的。它在截图中显示为0 KB,但在cmd中输入“start ms-windows-store:”会打开Windows应用商店,所以它可能只有一行,并有一种将其引导到Python页面的方法。)
最后,正如Chipjust所建议的,你可以使用本文中解释的DOSKEY之类的东西为Python创建一个新别名,例如: 如何设置Windows下命令提示符的别名
这是一个实现神奇功能的PowerShell脚本。
Remove-Item $env:USERPROFILE\AppData\Local\Microsoft\WindowsApps\python*.exe
我在这方面也遇到了问题,Windows在双击或cmd(命令提示符)时无法识别Python或Anaconda。
问题:无法在Windows中的“python”cmd中导入库。相反,Windows的“python”cmd将用户带到他们不想去的地方。 问题原因:在Windows“环境变量”中,Windows在“%USERPROFILE%\AppData\Local\Microsoft\WindowsApps”目录中添加了python.exe和python3.exe(我不知道这些链接到哪里)。
解决方案:我尝试删除WindowsApp目录中的python*.exe文件,但Windows不允许,所以我打开了“%USERPROFILE%\AppData\Local\Microsoft\WindowsApps”目录中的命令提示符,并键入:
del python.exe
del python3.exe
然后我创建了一个环境变量,链接到已安装的Python解释器链接。在我的例子中,它是C:\Anaconda3;C:\Anaconda3\脚本,以及其他一些良好的措施。