编辑：由于这个问题被要求在标准Python科学库（这是目标区域）中发生了很多改进。例如，numpy项目已经做了很大的努力来改进文档字符串。人们仍然可以争论是否有可能从一开始就不断解决这些问题。
我有这个有点异议的问题：为什么这么多Python库有杂乱的代码而不遵循标准的最佳实践？或者你认为这种观察绝对不是真的吗？情况与其他语言相比如何？我对你的看法很感兴趣。
我认为质量缺乏的一些原因：
*args和**kwargs但是没有记录可以给出哪些值时，这很痛苦。__init__之外添加新属性。这样的事情使得代码难以阅读（或维护）。别误会我的意思，我非常喜欢Python及其生态系统。即使我在这些图书馆中挣扎，他们通常也会完成工作，我很感激。但我也认为，由于这些问题，最终浪费了大量的开发人员时间。也许这是因为Python为您提供了如此多的自由，以至于编写糟糕的代码非常容易。
关于文档，它不仅仅是Python。如果有一个因素阻碍了OSS的广泛采用，那么恕我直言，大多数OSS项目的文档真正可怕。这从代码级别开始，并扩展到用户文档。我可以对从事OSS工作的任何人说：
a）评论你的代码！没有自我记录代码这样的东西！
b）将至少25％的项目时间预算用于最终用户文档。
而且我确实模糊地知道我在说什么 - 我有几个自己的OSS项目，我已经为其他几个项目做出了贡献，我几乎完全使用OSS。昨天我花了4个多小时试图建立一个主要的OSS项目（没有名字，没有包钻），并且由于蹩脚，自相矛盾的文档而失败了。
我认为Python太过于急切地被那些不是程序员（通过学校教育或交易）作为“需要一些编程完成的解决方案”的解决方案所困扰？在这里，试试这个简单而成熟的工具。
类似于PHP如何取得如此巨大的成功以及如此多的库具有极低的代码质量（即使授予，平均Python代码质量优于PHP） - 平均PHP用户与普通Python用户相似并没有太多编程他们在这方面的经验或技能以及改善自己的动力很小 - 他们着手实现某些目标，也许他们认为以图书馆的形式与社区分享是值得的，但大多数情况下，一旦工作完成他们没有兴趣改进代码或改善自己（在编程技巧方面，我的意思是）。
解决方案可能是针对Python库存储库（例如PyPI）有更严格的规则来接受提供的包 - 使用审核流程处理此问题，其目的是确保质量 - 与主要Linux发行版在添加包之前进行审核流程的方式相同他们的存储库。
PEP8就是一个惯例，而不是一个要求。如果所有的python程序员都必须遵守一套共同的规则，那将是非常难过的，我们会在最轻微的问题上失去热情。
至于缺少文档字符串 - 是的，它们可以在使用交互式帮助时提供帮助 - 但我通常不介意只要有一些文档。我尽量不读取我使用的库的源代码，我倾向于开始修改（重写）它们。
关于与其他语言的比较，我认为语言设计在这里起着重要作用。例如，在像Java这样的强类型语言中，即使库缺少良好的文档，您仍然可以从方法签名中推断出大部分功能。没有*args可以抗衡。
一组好的软件doc的例子怎么样？ 好的例子可能会导致整体改善比随机游走快一点。 该集合可以分为以下类别： 内联文档/帮助页面/教程/参考手册，网页/纸张，图片/无。 每个条目都应该有一些关于审稿人发现它的好处的文字。 （哪里：stackoverflow的一角？）
nikow：我只能自己回答，我的大部分Python（以及PHP或Ruby，所有动态“脚本”语言）工作都是为我完成的 - 但我总是在我的个人网站上发布它，如果其他人发现它有用，但是我从不经历任何文档或质量保证流程，因为只要它对我有用，我就很开心。
嗯，他们是开源的。因此，如果它们足够好，它们也会随着时间的推移而发展。
这是开源的众多美女之一。
如果您不知道该项目是否会继续存在，那么编写大量文档和“好”代码通常没什么意义。那只是浪费时间。
编辑：当然，写好的代码永远不会在第一次受到伤害...但在许多情况下，也许只是“完成工作”就足够了。我认为否则在OSS方面我们不会享受到大量的选择。
我认为，如果有足够的人采取特定的行动，可能会有一些解释。他们不只是随意冒犯你。
代码质量*评论数量*时间=常数
选择两个 ！
我使用matplotlib时没有遇到任何问题;不能说我看了很多代码 - 这是一个很好的库。应该做什么（免费！）
相反，作者每个人似乎都遵循他们自己光荣的惯例。有时，约定甚至与库的同一文件不一致
欢迎来到现实世界的精彩代码！
我见过的FWIW Python代码并没有比其他任何语言更好或更差。
（好吧，显然比一般的PHP项目更好，但这不太公平。）
你需要意识到的第一件事是，在版本2.x的某个时候，Python并没有完全形成。它在过去二十年中不断发展壮大。
事实上，你提到的一些事情（例如，unittest，例如，PEP-8），在首次编写一些标准库时甚至都不存在。
你可能会注意到，你所看到的图书馆越老，它们就越有可能与当前的“最佳实践”产生分歧 - 通常是因为它们早于广泛采用这些实践。最近的图书馆更有可能符合当前的做法。
此外，有时通常有充分的理由不让它们更新。想象一下，你有几万行代码针对当前的Python库编写。现在，其中一个库的维护者决定更改库以使类和函数名符合PEP-8。现在每个拥有工作代码的人都必须重新访问它，以免重命名破坏事物。
这并不是说Python库中没有可以改进的东西 - 有！但是在完美和完成任务之间总是需要权衡。这就是他们说“实用性超越纯洁”的原因之一。
这是因为Python不是像Java或.Net这样的企业世界备份的。
如果我希望Sun推广我的Java库，我将遵循他们的指导方针。 Python不是这种情况。我编写代码，人们发现它更好，它必须自己发展。
大多数Python开发人员也来自C ++，C，Java，.Net等。他们从第一天就开始编写生产代码。感谢Python的简单性。恶性循环仍在继续。
即使我花了一个月的时间来到PEP8并重构我的代码。
PEP 8随着时间的推移发生了变化。一些模块遵循较旧的建议。您可以看到使用PIL，它使用像“Image”这样的模块，其中模块包含单个主类，而不是模块名称的推荐小写，以及使用“c”前缀的C扩展，而不是更现代的“ _“ 字首。
一些库是由受Java和C ++等其他领域传统影响很大的人开发的。这些人更经常使用CamelCase而不是PEP 8推荐的lowercase_with_underscores。
如果不参考Sturgeon's Law，这里的答案就不会完整：“百分之九十都是废话。”
百分之九十的[python库]是粗糙的，但百分之九十的都是粗糙的
- 鲟鱼法（释义）
听起来您已经发现代码质量不符合您期望的预期。也许来自学校，或最佳实践书籍或高级开发人员。
在几家公司工作之后，我发现自己经常被建议做单元测试，文档代码，使用版本/源代码控制（我已经采取的所有好建议），然后发现该建议的提供者很少自己遵循建议。
我会说你确实有正确的印象，有时代码质量很低，但只能根据你的期望。当然numpy和其他是非常有用的包，即使没有按照你设定的标准编码。
标准是意见，如果你认为标准很低，那么你可以尝试通过贡献或者接受它们来帮助改进这些标准，并确保编写代码作为一个例子给你的小辈们会发现自己掌管一天。
至于matplotlib，有一个项目来改善它的“pythoness” - http://www.scipy.org/PyLab
关于科学图书馆的事情是，它们是由科学家编写的，而不是由专业软件开发人员编写的。转移，那些科学家习惯写Fortran。问题是 - 你宁愿拥有工作代码还是漂亮的代码？
PEP8是一种风格指南，而不是风格要求。它甚至声明你应该“知道何时不一致”。就个人而言，我不喜欢其中的一些指导方针。我更喜欢camelCase和snake_case，因为我已经习惯了。
我不经常查看我正在使用的库的源代码，除非它是绝对必要的（例如调试）。我更喜欢这个库的文档足够充分，我从来不必查看源代码。
说真的，为什么你真的关心matplotlib的源代码是什么样子，只要它能做到它的意图呢？
我同意你关于丢失的docstrings（假设它们是公共元素而不是内部元素），但这不是记录库的唯一方法。