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
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-leave@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/B4GZYQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Juancarlo *Añez*