Thanks for the explanation. This may be a bit OT, but is there a good way to do runtime assertions (in particular for data validation) that's as easy as assert?
- self.assertEqual (unittest.TestCase.assertEqual) is hardly usable in other class instances, - pytest can be used at runtime but has somewhat nontrivial overhead - I always end up writing e.g. _assert() and _assertEqual() that throw AssertionErrors and helpful error messages just like unittest. How do contracts differ from checking interfaces with e.g. zope.interface? https://zopeinterface.readthedocs.io/en/latest/verify.html I'll read up a bit more on design by contract. I seem to have conceptualized dbc as a composition approach with typed interfaces and type and value assertions, but that's not it? If the parameter value assertions in pycontracts aren't really contracts, and the mypy compile-time parameter and return type checks are not really contracts, and zope.interface verifications aren't really contracts; what does that leave in terms of abstract data types, preconditions, postconditions, and invariants? https://en.wikipedia.org/wiki/Design_by_contract On Monday, August 27, 2018, Steven D'Aprano <[email protected] > wrote: > On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote: > > Runtime checks: data validation & code validation > > Compile-time checks: code validation > > > > What sort of data validation is appropriate for assert statements or > > contacts that may be skipped due to trading performance for more risk > > ('optimized out')? > > That depends on what you mean by "data validation". > > Testing for bad input, or testing for predictable error states such as > I/O errors, missing files, permission errors, server down etc is > not appropriate for assertions (which includes contracts). > > The rule I use is that assertions are for: > > (1) testing your program state, which is under your control; and > > (2) communicating the intention of your program as executable > code rather than comments. > > The ultimate aim of contracts and assertions is to eventually disable > them when the program is bug-free. > > The Eiffel docs say: > > 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 [...] are available [...] 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). ... Bluntly: > > Rule -- Assertion Violation: A run-time assertion violation is > the manifestation of a bug. > > https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_ > %28tm%29%2C_Assertions_and_Exceptions > > For detecting *external* error states (anything to do with data that > comes from outside your program, like user input) you can never let your > guard down and never disable the test, because servers can always go > down, users can always give you bad data, files can always be corrupt. > It is unsafe to disable these tests and so these should not be > assertions. > > For a library function intended to be called by third-parties, the > function arguments aren't under the control of the library author so > should not be tested with assertions. But for an application where the > author controls those function arguments, they are under the author's > control and may be assertions or contracts. > > Design By Contract is partly a methodology and partly a set of syntax. > Its a way of thinking about the design of your program. In practice, you > don't have to buy 100% into DBC to get some benefit for it. A study done > a few years back looked at 21 large projects in Eiffel, JML (Java) and > Code Contracts for C# and found that 33% of the classes used contracts. > > http://se.ethz.ch/~meyer/publications/methodology/contract_analysis.pdf > > Like unit testing, you don't need 100% coverage to get benefit. 10% is > better than nothing, and 20% is better than 10%. > > I wrote more about assertions here: > > https://import-that.dreamwidth.org/676.html > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
