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 <pyt...@mrabarnett.plus.com> 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 <gu...@python.org > > <mailto:gu...@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 <apal...@gmail.com > > <mailto: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 > > <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 <mailto: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. > > > _______________________________________________ > 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/WA5RJXV4GTVJ42TBD55NMPNJV65RLF6M/ > 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/6V3ZK6A4I5237B6HQFIDI64OEQ2OPWTJ/ Code of Conduct: http://python.org/psf/codeofconduct/