Christopher,
The *if* version has the condition inverted, and it's structure makes it
look as part of the algorithm, instead of an assertion over an invariant.
Following with the ideas on this thread, it would be possible for -OO to
turn off only assertions with exceptions that descend from AssertionError.
More on my answer to Steven
On Thu, Sep 9, 2021 at 12:35 PM Christopher Barker
Take a look at the archives of this list -- there was a large conversation about DBC a while back (a year, two years ??? )
I think if you really want to support DBC, there will need to be more changes than this -- though there are libraries that support it with current Python.
Also, let's be clear about hte language re use -- when you say:
there should be lots of assertions, do you mean the english were assertion, or the Python keyword assert?
If the former, than you are free, or course, to use a ordinary if and raise to make all sort sof assertions about the code at runtime.
To me -- the entire point of the assert statement is that it is for testing, and can be turned off. If you want to check a condition always, just use an if and a raise:
How is this:
if value < 0: raise ValueError("this only works with positive numbers")
Any more difficult to read or write than:
assert value >= 0, raise ValueError("this only works with positive numbers")
-CHB
On Thu, Sep 9, 2021 at 9:05 AM Juancarlo Añez
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
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-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* _______________________________________________ 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/3HUS3M... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris)
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
-- Juancarlo *Añez*