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*
_______________________________________________ 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/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/ Code of Conduct: http://python.org/psf/codeofconduct/
