最近在使用 python 时，我遇到了一个非常奇怪的现象：从命令行执行
python.exe并不会进入 repl 模式，也没有其他明显的反应。然而，过了一会儿，系统却弹出了 windows store 页面，直接跳转到了 python app 的详情页。
这个现象让我一度以为是 Python 运行环境出现了问题，但很快我意识到，这应该是 Windows 系统搞的鬼。
我检查了路径是否正常，结果发现：
$ where python C:\\Users\\yuhao\\AppData\\Local\\Microsoft\\WindowsApps\\python.exe
原来，系统自己创建了一个
python.exe。如果在资源管理器中打开上述目录，会发现这里只有几个孤立的 .exe 文件，且图标也不正常，这显然不是一个完整的 Python 运行环境。
那么，Windows 为什么要创建这些没有实际环境的 .exe 文件呢？
立即学习“Python免费学习笔记（深入）”；
通过网上的一些信息，我了解到自 Windows 10 2019 年五月更新以来，微软试图将 Python 引入 Windows。具体做法是将 Python 3 放入自己的应用商店。而上面看到的
python.exe实际上是一个“假的” Python，其唯一作用是在系统找不到 Python 时，自动跳转到微软商店，让用户下载。
微软团队对此的解释是：Who put Python in the Windows 10 May 2019 Update?
可能是担心这个新功能会导致一些兼容性问题，微软在系统设置中添加了一个比较隐蔽的功能。比起在层层叠叠的设置界面中寻找它，更简单的方法是直接输入
app exec：
这样会打开设置的“应用程序别名”界面。在这里，我们会看到系统认为
python.exe和
python3.exe只是安装程序的别名，我们可以选择关闭它们。这样，当我们再次运行 python 时，就会显示“找不到程序”的标准提示。实际上，Windows 是将上述 .exe 文件偷偷备份到了其他地方。
许多程序员（包括我自己）通常会按照标准方式从官方网站下载并安装 Python。如果在安装过程中选择了“添加到系统环境变量”，那么标准 Python 会注册到系统 PATH 变量中，而前面提到的
WindowsApps目录则是 Windows 添加到用户 PATH 变量的。根据 Windows 系统的规则，PATH 环境变量是系统设置优先于用户设置，所以如果安装了标准版 Python，系统应该首先找到的是它，而不是应用商店版的 Python。后来我发现，我的机器之所以会出现上述问题，是因为系统设置中有一点语法错误，修正后再次测试，结果就正常了。
到此，我们已经理解了 Windows 自带的 Python 是怎么回事。微软这样做的初衷应该是希望普通用户能更方便地使用 Python，这个想法无可厚非，但将 Python 放入 Windows 应用商店的设计思路是否合理，我还是持怀疑态度。毕竟，微软应用商店一直以来名声不佳，内容少、功能欠缺、速度慢，时不时会出现一些恼人的小问题（比如不知所云的 0x8000xxxx 错误）。而“应用程序别名”这个功能到底是解决了问题还是带来了更多的困惑，我也持保留意见。
当我在网上查找关于该问题的信息时，也发现有其他用户同样受到该问题的困扰，比如：
[Bug] Don't find python library from WindowsApps dir Microsoft Store installed python (3.7 - Windows 10) based virtualenvs cannot access pyd DLLs 目前，在 Windows 上安装 Python 有许多不同的方式：
- 通过官方网站下载安装；
- 通过
Anaconda
集成软件包； - 和
Visual Studio
一起安装； - 通过
chocolatey
之类的第三方包管理； - 通过
WSL
安装 Linux 版 Python； - 通过 Windows Store 安装；
说实话，我认为太多不同的来源渠道会使环境问题变得更加复杂，增加出错的可能性，并且容易迷惑初学者。对于大多数程序员来说，建议还是按照最基本的方式，从官方下载并安装 Python。
（完）
