一个 Pythonic 的类应不应该在 __init__ 中检查参数有效性？

我知道按照鸭子类型原则，是不应该检查参数类型的。但是应该检查参数在其他方面的有效性吗？例如：
class Comment(object):
... def __init__(self, content, creater, ipaddress):
... ... self.content = content
... ... self.creater = creater
... ... self.ipaddress = ipaddress
似乎大家一般都这么写，而不检查 ipaddress 是否是有效的 IP 地址。
Python 的编码宗旨似乎是信任开发者，所以 private 之类的设计都没有。那么我们的信任应该到“不检查参数有效性”的程度吗？

回复内容：

其实这个问题已经被讨论过了，“我们都是成年人” （After all, we're all consenting adults here.）

简单翻译一段：

Nothing is really private in python. No class or class instance can
keep you away from all what's inside (this makes introspection
possible and powerful). Python trusts you. It says "hey, if you want
to go poking around in dark places, I'm gonna trust that you've got
a good reason and you're not making trouble."

After all, we're all consenting adults here.

Python中没有东西是真正private的. 任何类和对象都不会阻止你窥探他们的内部，这使得Python的自省异常强大. Python 对你的态度是信任的，它说：“hey，如果你想尝试使用黑魔法，那么放心大胆的去吧，我相信你一定是有自己的理由的，知道自己在干嘛，并且不会捅出篓子，懂得点到为止”

话说回来，大家毕竟都是成年人了，懂得为自己的行为负责，都知道自己在干嘛，所以你想干什么我不会拦着你。

我想这种设计哲学才是 Python 与 Java 等语言的根本区别，对于参数检查也是一样的，不检查你的参数，因为信任你。但是出了问怎么样呢？当然是抛异常。抛了异常，你就要自己负责（在合适的地方 try except，并且假设你知道捕获异常后应该怎么处理）。

再扯的远一点，这种思想贯穿在 Python 中很多地方，比如想让一个 Generator 结束，可以抛一个 StopIteration 异常，异常不是洪水猛兽，而是一种正常现象，异常的正确抛出和捕获保证了世界正常运转，在 Python 里重要性堪比控制流。为什么呢？也是一种信任的思想，相信异常可以被正确处理，也应该被正确处理，并且已经在语言自身中处处都被正确处理着。

题主所写的那个类，如果你传了一个有问题的参数，那程序通常就会在应该出问题的地方抛异常。而这个类的作者——你作为一个成年人，对这个异常应该能正确处理，这是对你信任。你应该知道怎么处理这个异常，包括你知道在有必要的时候应该做一定的参数检查（这不冲突，依旧是信任。所以你看，你想做参数检查Python也不拦着你）。

小时候什么都不懂，我说想自己骑车去另一个城市玩，被我妈拦住了（参数检查）.
如果我现在说要去，我妈说：“你是成年人了，你应该有自己的理由吧，照顾好自己，但是你出行的一切问题由你自己负责”（信任，不限制，假设使用者能够自己对问题负责）。

全文，见：[Tutor] What is "pythonic"? 输入参数的检查是防御性编程的一部分

在你不信任输入的时候，比如这是用户提供的数据，或者另一台服务器提供的，那应该就要检查

但是未必要在类初始化时检查，如果这个是 Model 类，也可以在写入数据库之前检查

如果这个输入，是由一个值得信任的模块提供的话，或者已经经过一轮检查，就没必要重复了
Python 的宗旨是信任开发者会遵守开发约定，但不是说信任开发者的程序没有 Bug，和防御性编程也没有任何冲突 在文档里标明需要什么样的数据就好了。Python 官方是不支持不必要地检查类型的。既然连类型都不检查了，为什么要检查值的有效性呢？C 语言也同样不会总是去检查用户传过来的东西是不是正确的——这是调用者的责任，库的责任在于把文档弄好，别让人猜哪里该传入何种数据。

在 Python 中，不合法的数据传入之后总是会导致异常发生的（否则你为什么说它不是合法的？）。如果你马上要把那个 IP 地址存储到数据库中，或者交给 C 函数使用，那么肯定是要检查的；如果是传给 socket.connect 之类的，何必检查呢？你又能否做到正确地检查？（绝大部分网站注册时的 Email 检查过严，比如不允许 + 号；至于 IP 地址，有多少人考虑到了 IPv6？你们都知道秒的取值范围是 0-61 吗？）

个人的理解是这是一个与语言无关的问题，不仅仅是python。

将业务的处理和检查传入的参数做分离是一个不错的选择，但是这个分离是类级别，还是方法级别可能就需要根据具体的业务权衡后决定。可能需要实现的功能比较简单，参数也比较简单，方法级就可以了，如果后续需求变更了，业务逻辑复杂了，再重构代码也不迟。

基于单一职责原则，一个类做好一件事。个人比较偏爱业务处理成一个独立的类，参数检查为另一个类，并将这两个类放一个文件。

江阁同学的疑惑是：是否应该检查参数除类型外的有效性。
从安全、数据完整性等方面考虑，这种类型检查是有必要的，如前面依云同学提到的数据库操作等。这些检查应该是与具体业务相关的，不应该是在最后写入前再检查（写入前也是要检查的，不要相信输入）。 简单的答案是：Python代码不应该设计成需要类型检查。如果你觉得需要，就说明设计有问题。
这篇stackoverflow的答案很好，建议阅读：
http://stackoverflow.com/questions/734368/type-checking-of-arguments-python 事实上，你完全可以通过metaclass等机制构建一个强制类型检查的类。 输入可能不规范就要检查, 不过不一定在__init__里, 可以调另外的函数, 比如
self.ipaddress = self.validateip(ipaddress)

其实不用太在乎什么python规范, 很多东西没什么规范, 视事而为.


另外检查ip地址推荐谷歌开源的python库 http://code.google.com/p/ipaddr-py/
类不检查，哪就在输入的时候把把关就可以了。 Duck typing 不需要检查代码类型的逻辑是：当类型不合适的时候自然会出错。但这与防御性编程并不矛盾。你仍然应该在模块边界对输入有效性进行判断，不然等到长长的调用链末端（如果是传入类构造函数存储起来，调用链早就断了）才发现不合适的时候，你怎么调试？ 给自己以及项目组其他人这个地方的"默契" 是, 非业务逻辑代码比如corelib, utils 对参数进行检查, 业务逻辑部分用户输入检查...其他的并不强制.