assert cond:
# Write some debugging info to a log.
...
raise ExtType(args)
I like the idea of preparing the arguments for the assertion message in a
context that gets executed only when the assertion fails.
On Thu, Sep 9, 2021 at 7:16 PM MRAB <[email protected]> wrote:
> 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 <[email protected]
> > <mailto:[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]
> > <mailto:[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
> > <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] <mailto:[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.
> >
> _______________________________________________
> 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/WA5RJXV4GTVJ42TBD55NMPNJV65RLF6M/
> 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/6V3ZK6A4I5237B6HQFIDI64OEQ2OPWTJ/
Code of Conduct: http://python.org/psf/codeofconduct/
