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/
