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 <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/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/6A5N42SWT7RGW5O3PXZ7LZPIUXLVQXUU/
Code of Conduct: http://python.org/psf/codeofconduct/
