Cheese Shop 菜单的外皮

标题是对优秀 Python Package Index 中最常被遗忘的昵称的引用——奶酪店——它指的是 Monty Python Cheese Shop 草图。我经常发现自己盯着 piwheels 监视器，偶尔会弹出一个奇怪的包名或异常长的版本号：我最近做了很多审计 piwheels 与 PyPI，确保我们有正确的包和版本集，修剪本应删除的内容并添加任何以某种方式被遗漏的内容。我遇到了很多有趣的怪事，所以我想我会做一些分析和探索，并在这里分享结果。以下分析是前几天从PyPI得到的一组包和版本，当时有： 最不常见的包名长度为72, 73, 74, 75, 80, 82, 83, 90, 92 ——所有这些都发生一次。包名最常见的起始字符是 p (14%)，因为很多包被命名为“py”-something 或“python”-something。其次是 d (9%) 由于“django-”包。其余字符集的分布是： 查看前两个字符，最常见的是 py、dj、od、co 和 re：

本福德定律指出，在许多自然发生的数字集合中，前导数字可能很小，因此每个后续数字的分布不太可能。我想知道这是否可以在包版本号中看到。取数字版本，并查看第一个非零数字，该分布合理地符合 Benford 定律：然而，查看所有数字（不仅仅是第一个）的分布，这与 Benford 定律提出的模式非常相似更接近：在这两种情况下，1 比预期更常见，2 似乎完全对齐，但 9 比预期稍微更常见，在第一个数字示例中更是如此。我排除了没有版本的包（因为它们在 PyPI 上没有 JSON 端点）。至于其余的，超过四分之一只有一个版本。随着版本数量的增加，频率稳步下降：PyPI 包版本不必是严格的数字——它们通常采用 1.2.3 或类似的形式，有时附加字符以表示 alpha、beta、dev 或 release候选，但它们可以是任何字符串。最长的版本是包lyricsprocessor的一个版本，具有版本号0.1.40404040404040404040404040404040404040404040404040404040404040404040404040404040（84个字符）的下一个最长的都来自包softwarefabrica-django的-utils的排它具有70个字符的版本例如1.0dev-BZR-R115-panta- elasticworld.org-20100520155735-sf3yrsr0pvyvlm8m

在 PyPI 的历史上，有人不小心提交了他们包的描述作为版本名称，所以有一个包 sysv-ipc 的版本叫做：Sysv_ipc 允许 Python 程序访问 System V 信号量、共享内存和消息队列。大多数（全部？）Unix（包括 OS X）支持 System V IPC。 Windows+Cygwin 1.7 也可能工作。包含示例代码。此扩展在 GPL 下发布。您可能还对类似的 POSIX IPC 模块感兴趣：http://semanchuk.com/philip/posix_ipc/ 其他时候这种事情是偶然发生的，包括第一个版本的 omnijson，它被称为“Kenneth Reitz”并且是还活着：我最近注意到一个版本的末尾似乎有空格，然后看看是否还有其他版本。 PyPI 上有 16 个以换行符结尾的版本。在这 16 个中，有 12 个也注册了剥离的等效项：由于版本号往往是数字，因此最有趣的肯定是那些没有任何数字的版本。由于该版本在其发行版中包含一个 tarball，您可以检查此事故是如何发生的。许多用于计算版本号的复杂代码……出错了。版本字符串实际上是 Version 类的代表，而不是实例的字符串表示，正如预期的那样。通常它会显示为 <__class__.jw.util.version.Version> 但它已被规范化，用单个连字符替换尖括号和双下划线。有趣的是（如果你已经做到了这一点，我认为你是那种会觉得这很有趣的人），在具有非数字版本的 166 个软件包中，除了五个之外，所有软件包都只有一个非数字版本版本，而这五个版本各只有两个这样的版本。那些是：

您可以在 GitHub 上查看笔记本以了解围绕此分析的工作，包括我如何使用 XMLRPC 和 JSON API 从 PyPI 获取数据。