Well, if the idea makes sense, then I'm certain that we'll have a very long
and productive discussion about the best syntax here (re: *:=*).
;-)
For backwards compatibility and no surprises:
*assert: *ExType, cond, args
It doesn't break anything, ExtType defaults to AssertionError, and linters
can check that *args* match ExType.
A more readable and pythonic syntax would be:
*assert *cond: ExtType(args)
Forgoing the comma doesn't break anything, linters can check the ExType()
typing, and the semantics would be those of:
*if* __debug__ *and* *not *cond:
*raise* ExType(args)
Although I would drop the check for *__debug__* if an explicit ExtType is
given.
It's similar to the changes introduced for:
*except* (OneEx, TwoEx):
On Thu, Sep 9, 2021 at 12:16 PM Guido van Rossum <[email protected]> wrote:
> Ooh, that’s a nice idea. If the message is an exception instance, raise it
> instead of AssertionError. Unfortunately it’s not 100% backwards
> compatible. We could address that with the syntax
>
> assert cond, raise=ExcType(args)
>
> Maybe we could deprecate the case
>
> assert cond, ExcType(args)
>
> So that eventually the raise= keyword can become optional.
>
> —Guido
>
> On Thu, Sep 9, 2021 at 09:04 Juancarlo Añez <[email protected]> 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 <[email protected]>
>> 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 -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/[email protected]/message/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> Juancarlo *Añez*
>> _______________________________________________
>> Python-ideas mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
>
--
Juancarlo *Añez*
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/O4LLILQJWNTS4JTTI2BUZ7CGLG4V3YMA/
Code of Conduct: http://python.org/psf/codeofconduct/
