> This is better achived, not by littering the functional code unit with > numerous assertions that obscure the normal function of the code, but > rather by employing comprehensive unit tests *separate from* the code > unit.
that doesn't seem to work too well when shipping a library for someone else to use... we don't have access to the caller's code that needs to be checked. I suppose if the intent is to have a true assert, that does nothing in shipped code, then you can argue that testing addresses some of the issues, but one, not all of them, specifically, not the part where the problem is ably reported, and two, I don't think we can assume assert meant that sort of assert macro in C which compiles away in release versions. Asserts also do not litter code, they communicate the assumptions of the code. I like the idea of a general duck-type assertion and would probably use that, especially since I also have arguments which can be multiple objects, each with their own interface but similar meaning... i.e. lower level file objects can be passed in, or my higher level abstraction of the same file. -- http://mail.python.org/mailman/listinfo/python-list
