Ooh, that’s a nice idea. If the message is an exception instance, raise it instead of AssertionError. Unfortunately it’s not 100% backwards compatible. We could address that with the syntax
assert cond, raise=ExcType(args) Maybe we could deprecate the case assert cond, ExcType(args) So that eventually the raise= keyword can become optional. —Guido On Thu, Sep 9, 2021 at 09:04 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* > _______________________________________________ > 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/ > -- --Guido (mobile)
_______________________________________________ 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/ADQCK6Z4QLMXDDVRILAZROFOJD3T6YSJ/ Code of Conduct: http://python.org/psf/codeofconduct/
