On 2021-09-09 22:31, Juancarlo Añez wrote:
> 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)
>
>
Or, perhaps:

     assert cond: raise ExtType(args)

That would make it more like an if and would leave open the possibility
of extending it to accept multiple lines:

     assert cond:
         # Write some debugging info to a log.
         ...
         raise ExtType(args)

Just a thought.

> 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 <guido@python.org
> <mailto:guido@python.org>> 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 <apalala@gmail.com
>     <mailto:apalala@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
>             <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
>         <steve@pearwood.info <mailto:steve@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.
>
_______________________________________________
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/WA5RJXV4GTVJ42TBD55NMPNJV65RLF6M/
Code of Conduct: http://python.org/psf/codeofconduct/