Marko Rauhamaa wrote: > Asserts are not about notification, checking or optimization. They are > about communicating what's going on in the programmer's mind. They are > comments.
Assertions can be used for *all of these things*. Assertions can be used for: - checking internal program logic; - testing pre- and post-conditions; - testing program invariants; - comments which are verified at runtime; > So why use asserts instead of comments? Not all comments can be replaced with an assertion, but some can: # once we reach here, mylist has at least two items is better turned into an assert: assert len(mylist) >= 2 To someone who is fluent in Python, the assertion is as easy to read and understandable as the English comment. And it has the added benefit that the interpreter will verify that the comment is correct at runtime. Verifying comments is important, since programmers are notorious for ignoring comments and failing to update them: http://import-that.dreamwidth.org/956.html Why would you choose a comment rather than an assertion? If the code is performance critical, and the extra cost of the assertion is significant, and you cannot reasonably run the code using -O to disable it, then a comment might be better. > Asserts *could* help in fixing bugs: > > 1. An assertion failure immediately, unambiguously, declares even to > customer service representatives that this is a terrible bug and > should be brought to R&D's attention instead of hazing the poor > customer with standard questions ("have you updated?", "have you > rebooted?"). If only that were the case :-( > 2. An assertion failure probably gives the developer an very good clue > as to what has gone wrong. There is a good chance of quickly > finding an accurate analysis and fix to the bug. In general, it is desirable to have any eventual exception occur as soon as possible to the ultimate cause of the exception. Assertions can aid in that. Languages such as Eiffel provide a rich and powerful set of different assertions, including: require ensure check debug invariant The Eiffel manual is explicit about the correct use of assertions: It should be clear from the preceding discussion that contracts are not a mechanism to test for special conditions, for example erroneous user input. For that purpose, the usual control structures ( if deposit_sum > 0 then ...) are available, complemented in applicable cases by the exception handling mechanism reviewed next. An assertion is instead a correctness condition governing the relationship between two software modules (not a software module and a human, or a software module and an external device). If sum is negative on entry to deposit, violating the precondition, the culprit is some other software element, whose author was not careful enough to observe the terms of the deal. Bluntly: Rule -- Assertion Violation: A run-time assertion violation is the manifestation of a bug. [...] That violations indicate bugs explains why it is legitimate to enable or disable assertion monitoring through mere compilation options: for a correct system -- one without bugs -- assertions will always hold, so the compilation option makes no difference to the semantics of the system. https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions -- Steven -- https://mail.python.org/mailman/listinfo/python-list