在设置虚拟环境时，sys.path 的值在 Windows 和 Linux 之间有所不同

Question

通过python -m venv .venv创建虚拟环境然后激活此环境时，我注意到在Windows上，环境的根目录是sys.path报告的导入路径的一部分，但对于linux来说，它不是。

蟒蛇版本：3.8.2

例：

python -m venv .venv

在视窗上：

>>> import sys
>>> sys.path
['', 'c:\temp\.venv\Scripts\python36.zip', 'C:\Python36\DLLs', 'C:\Python36\lib', 'C:\Python36', 'c:\temp\.venv', 'c:\temp\.venv\lib\site-packages']
>>> sys.prefix
'c:\temp\.venv'

请注意路径中的条目c:\temp\.venv。

在 Linux 上：

>>> import sys
>>> sys.path
['', '/usr/local/lib/python38.zip', '/usr/local/lib/python3.8', '/usr/local/lib/python3.8/lib-dynload', '/carsten/.venv/lib/python3.8/site-packages']
>>> sys.prefix
'/carsten/.venv'

请注意，环境的根不是路径的一部分。

这是设计的差异还是错误？

Answer 1

Windows 案例除了由 site.py 添加的 venv 前缀目录外，还具有由解释器启动代码添加的已安装前缀目录"C：\Python36"。添加这些目录是很久以前的遗迹。没有令人信服的理由认为"C：\Python36"或"C：\temp\.venv"需要放在sys.path中。尽管某个地方的某个人可能依赖于它。

添加前缀目录曾经在 1990 年代的 Windows 版本的早期版本中是高效的，该版本最初将标准库扩展模块放在前缀目录中，而不是专用的"DLL"子目录中，此外它还使用站点包的前缀目录。例如，请参阅 1997-08-09 的 site.py。几次迭代后，Unix中添加了"site-packages"，但Windows仍然使用前缀目录。

最后，几年后的 2001-07-12，"site-packages"被添加到 Python 2.2 的 Windows 版本中，但除了前缀目录之外，而不是在sys.path中替换它。这是由 Paul Moore(仍然是活跃的核心开发人员(在 PEP 250 中提出的，他指出保留前缀目录是为了支持添加在那里的 .pth 文件。

在当前的 site.py 实现中，addsitepackages调用getsitepackages，如果路径分隔符是反斜杠(鉴于可用的更好方法，这是一种识别 Windows 的奇怪方法(，它首先添加prefix然后os.path.join(prefix, libdir, "site-packages")。