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 <python...@gmail.com>
wrote:
> 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
>
--
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/NUMG45VJ47G4B5CZLZZSNBTKJUZ2ZK7N/
Code of Conduct: http://python.org/psf/codeofconduct/
