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/
