@kuanat #58

我的疑问是，__all__和你提到的文件系统大小写敏感几乎没有关系。因为解决大小写不敏感所带来的问题的方案主要是通过规范要求名称都是小写。而且不管有没有__all__，import *都可以使用，只不过没有__all__会默认导入所有非下划线开头的名字。但正是这一点，让我很疑惑为什么要扯上__all__。也许你提这个目的单纯是想说__all__的诞生的历史是在规范模块名之后提出的？除此之外我看不出__all__和文件系统大小写不敏感有什么关系。

正是前面这一点我没看懂，所以之前还有一点也没继续问下去。其实还有一个问题就是，你#48 提到：
> 这个时间点上，如果 Python 决定重写 import hook ，将版本号纳入成为包名的一部分，支持安装同一个包的多个版本，就没有今天虚拟环境什么事了。
为什么这样能解决需要虚拟环境的问题？按我所理解的，go 之所以能把所有 mod 都哦下载到$GOPATH/pkg 下，然后在加上版本区分，完全是因为二进制文件能够记录编译时的版本号（说的更完整一些，完全也可以静态编译）。

而对于脚本型的语言，没有一个地方记录库对应的版本，因此这类语言采取的方式都是设置对应的 PATH （比如 PYTHONPATH 等等），然后在 PATH 中寻找最先遇到的库的版本导入。如果你要多版本共存，在同一个 PATH 下，遇到同个包的两个版本，该导入哪个？

@kuanat
> 为什么 Python 需要 __all__ 来支持 from XXX import *
__all__不是拿来指定哪些是公开接口，哪些不是吗？你给出的回答似乎和为什么需要__all__没什么关系？？？

还有所谓多版本共存的问题，这不是真正的问题所在。

对于编译型的语言，编译（链接）时，会在生成的可执行的文件里记录对应的版本号。在运行时，则会根据可执行文件中记录的版本去动态链接对应的库。这里的多版本库的共存的机制其实不是语言本身的，而是 ELF 文件格式提供的（以 linux 为例，windows 应该也有类似的机制）。

但对于脚本型语言，你的脚本里没有记录依赖的库版本（并且也不该在代码级别处理版本依赖）。
因此即使你在安装的库的版本里，加了版本后缀作为区分又有什么用呢？因为你脚本本身没有记录到底使用的哪个版本。

python 的虚拟环境和其他语言的依赖管理工具是类似的，解决都是依赖管理和隔离的问题。

pip 安装包时，把包安装在了系统/用户路径。而不同项目使用同一个系统/用户路径就会有依赖冲突的问题。所以有了虚拟环境这个概念，来隔离不同项目使用的不同版本的依赖。

而其他语言的工具链可以直接把包安装到当前项目的路径，然后当前项目的库路径加入到库加载路径里（比如 CLASSPATH ）。因此这些语言没有虚拟环境这个概念。

实际上楼上也有人提到了，python 其实也可以学习这个做法，把所有包安装到项目的目录下，然后设置 PYTHONPATH 。

光从排列组合的数量来讲，并不是能允许的密码数量越多越就越安全。

一个禁止 123456 和 654321 的系统会比不禁止的安全，因为这两密码太常用了。

Windows 10 IoT Enterprise LTSC 2021
一直支持到 2032

按照官方文档给的步骤更新就是了。

上游在打包的时候，自然会控制不同版本的仓库间的包不会出现太大的跨度。比如某个包从 v1 升级到 v2 ，这种升级一般都不会出太大的问题。

滚动更新是因为根本无法预测到底是从哪个版本升级到哪个版本，所以长时间不更新后再次更新，从 v1 一下升级到 v10 （只是据个例子，现实不一定会遇到），遇到复杂的依赖问题，自然容易滚挂。

对于旧包，很多包管理器都提供清理不再需要的依赖的功能（比如 apt autoremove ），或者清理旧版本仓库中存在的包，但是新版本仓库已经移除的包（ aptitude purge '~o'）

@zizon 试了一下，好像符号链接就行，虽然每次从其他机器 pull 都要手动创建符号链接。

@CivAx 你说的收邮件那更是另外一回事了。也是需要域名所有者设置 mx 记录到 mailgun 的邮件服务器，从而 mailgun 能接收邮件，再给你 route 到 outlook 。

如果你要收第三方邮箱的信件，要么通过 IMAP/POP 用户名密码读取对应的邮箱，要么设置 mx 记录从而域名下所有邮件都发到你这里。这都是需要第三方参于的。
而发邮件的逻辑却是直接采用了伪造发信者的方法。正是从收发邮件的逻辑来比较，我认为发邮件允许用户随意伪装所存在的不合理的地方。

@CivAx 这个特性和 mailgun 、amazonses 之类的邮件服务是两码事吧。

mailgun 之类的服务，通常是通过域名所有者设置对应的 SPF/DKIM/DMARC 记录来完成，并且收发邮件时接收方也可以验证。

比如接入 mailgun 这类服务提供商，通常是把子域名解析到第三方的 SPF/DKIM ，并且把 DMARC 记录里 aspf 和 adkim 设置为 relaxed ，从而允许子域名可以作为根域名通过检查。这样 mailgun 则可以通过子域名代发邮件，收件人也可以通过验证子域名的 SPF 和 DKIM 签名来验证。

类似的，包括前面有人提到的同个部门之间可以相互代发，如果子域名和根域名本身就属于同个实体控制下的，所以允许他们相互代发很正常。

但是 outlook 这种是直接修改 From 成另外一个域名，这完全是任何一个邮件伪造者的做法。