Let me re-*assert* ;-) External tests will not be invoked at runtime, yet failures *_will_* occur at runtime because of a variety of environmental factors (including cosmic rays).
Software should assert at least some of its preconditions, postconditions, and invariants. How can we make that easy and syntactically pleasant? On Thu, Sep 9, 2021 at 12:02 PM Juancarlo Añez <apal...@gmail.com> wrote: > Steven, > > The purpose is to make it easier to make software more resilient. > > The inspiration was this article that reminded me that software *_will > always fail_*, and also reminded me about all the discussions around DBC > and Eiffel: > > https://www.youtube.com/watch?v=AaZ_RSt0KP8 > > > IOW, my premise is that we should be using *_lots_* of assertions, > *_always_*, and that for that we need to make them easier to write, and > easier to handle in the event of the unavoidable failures. Seeking > unit-test coverage is not enough because unit tests don't run in production. > > I will concede that code written under the *"Python culture"* tends to be > resilient because the semantics of defaults and border conditions are > explicit in the documentation, and implemented thus. > > Perhaps it's enough to allow for: > > *assert **cond**, *ExType(args) > > > > On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano <st...@pearwood.info> > wrote: > >> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: >> > I won't propose a syntax, but I think it would be useful if *assert* >> could >> > raise an exception different from *AssertionError*. >> > >> > This is in the context of "Design by contrast" (DBC) as a useful >> companion >> > to "Test-driven development" and other forms of external tests. >> >> I don't see why that would be useful. DBC assertions are assertions. You >> are *asserting* that a condition is always true. Since it is always >> true, it should be safe to disable those DBC assertion checks once your >> software is in production. >> >> I could *maybe* see that having fine distinction between pre-condition, >> post-condition and invariant failures would be useful, but without a >> system in place to allow those to be globally enabled/disabled >> separately, what's the point? >> >> In any case, in the event of a contract failure, there's really nothing >> you can do except log the error and exit. Raising errors like TypeError >> etc will encourage people to abuse assertions and contracts by catching >> those exceptions, for checking caller-supplied parameters and user data, >> or for flow control. >> >> >> -- >> Steve >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Juancarlo *Añez* > -- Juancarlo *Añez*
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PZMYE7KOWWILJPWEENNCFXVEQOWL3W7J/ Code of Conduct: http://python.org/psf/codeofconduct/
