这意味着它将选择包的最新版本，大于或等于0.6.10，但仍在0.6。*版本，所以它不会下载0.7.0，例如。如果包维护者尊重语义版本控制(即只在主要版本中发生破坏性更改)，它可以确保您获得安全修复，但保持向后兼容性。

或者，正如PEP 440所言:

对于给定的发布标识符V.N，兼容的发布子句大约等价于一对比较子句: >= v. n， == v. *

PEP 440中的定义 文档中有完整的示例

兼容的发布子句由兼容的发布操作符~=和版本标识符组成。它匹配预期与指定版本兼容的任何候选版本。

你可以在这里阅读更多:https://www.python.org/dev/peps/pep-0440/#compatible-release

这是“兼容发布”版本说明符。

它相当于:mock-django >= 0.6.10， == 0.6。*，是一种匹配期望兼容的版本的简洁方式。说白了，这有点像在说:“我需要一个mock-django的版本，它至少要像0.6.10一样新，但又不能新到与它不兼容。”

如果你不确定所有这些版本号的东西，快速看一下PEP440版本方案应该会让你理清头绪!

~=表示兼容版本。不低于0.6.10或更高(0.6.*)。

除了现有的答案，我认为还有一点非常重要，那就是

~=0.6.10表示>=0.6.10，==0.6

以下也是正确的

~=0.6表示>=0.6，==0

PEP文档中提到了这一点。

兼容发布(包括前发布和后发布)的完整定义是:

兼容发布条款由兼容发布组成 操作符~=和版本标识符。它匹配任何候选版本 期望与指定的版本兼容。 指定的版本标识符必须是标准格式 版本方案描述。本地版本标识符不是 在此版本说明符中允许。 对于给定的发布标识符V.N，兼容的发布子句是 近似于一对比较子句的:

>= V.N, == V.*

此操作符绝对不能与单个段版本号一起使用，例如~=1。 例如，以下两组版本子句是等价的:

~= 2.2
>= 2.2, == 2.*

~= 1.4.5
>= 1.4.5, == 1.4.*

如果一个预发布、后发布或开发发布被命名为 compatible release子句作为v.n.后缀，则该后缀将被忽略 当确定所需的前缀匹配时:

~= 2.2.post3
>= 2.2.post3, == 2.*

~= 1.4.5a4
>= 1.4.5a4, == 1.4.*

发布段比较的填充规则意味着 兼容发布子句中假定的向前兼容程度 是否可以通过向版本附加额外的零来控制 说明符:

~= 2.2.0
>= 2.2.0, == 2.2.*

~= 1.4.5.0
>= 1.4.5.0, == 1.4.5.*

请注意，这在语义版本控制预发布中并不适用。

例如，2.3.4.dev123+abc应该是> 2.3.3和< 2.3.4

但是~=2.3.4.dev123+abc在发布时不会接受2.3.4。