我在 Python 的线程模块源码中注意到了这一点：
def Event(*args, **kwargs):
return _Event(*args, **kwargs)
class _Event(_Verbose):
...
假设这是在尝试模仿其他语言中的“密封”类 (c#) 或“最终”类 (java)，我是否正确？这是 Python 中的常见模式吗？在 Python 中有没有其他方法可以解决这个问题？
【问题讨论】：
我认为我不喜欢这种标识符选择。按照惯例，类名以大写字母开头，因此您认为可以说 isinstance(x, Event)，但实际上不能。我认为像make_event 这样明确地将函数标识为函数的名称会更好。
这个问题已经在邮件列表中discussed，其中BDFL states：
这最初是作为 API 中的一个实验 设计，我试图让事物看起来很相似 尽可能使用 Java API（我不想再发明另一个摇摇晃晃的 车轮）。我特别希望这些不是成为类，以便人们 不会开始对它们进行子类化。当时 PEP-8 并不好 建立（如果有的话），我希望工厂功能看起来 喜欢上课。我认为在 2.7 / 3.1 我们可以更改工厂功能 符合 PEP-8（保留旧名称 释放）。
他提到的改变还没有完成，但我认为现在可以肯定地说，现在的命名方案被认为是错误的，不应该扩散。
当您说这些工厂函数被引入以模仿密封类时，您是对的。 BDFLsays
允许它们被子类化使得在某些情况下替换它们变得更加困难 具有等效但更快实现的平台。
我认为这种方案不太常见。大多数时候，没有动机用等效的实现替换类，如果一个类不是为子类设计的，您可以在文档中提及。
【讨论】：
这似乎是这个想法，但显然，如果你愿意，它仍然完全可以从类继承（即使它们在单独的模块中，你也可以通过 type(Event()) 获取参考。大概只是旨在让人们在子类化之前进行思考。
这不是 Python 中的常见模式。我们特别不鼓励继承的东西很少。
【讨论】：
Event 无疑是一个函数，它的名字打破了风格指南。它不是那么有害（文档清楚地表明它是一个函数），但我认为你不应该复制这个命名方案。另见mail.python.org/pipermail/python-dev/2008-September/082117.html