Steve,
I've seen *unless* discussed and rejected before, but it is a good enough
syntax for the purpose of asserting invariants, and it should be useful for
other purposes (because it has been proposed before).
The semantics are clear, and the implementation is simple with the new
Python parser
On Sat, Sep 11, 2021 at 02:37:25PM -0400, Juancarlo Añez wrote:
> David,
>
> It seems I didn't state clearly enough my original statement, which is that
> software will *_always_ *fail, even because of faulty hardware components,
> or cosmic rays.
If you expect your software to be resilient
On Sat, Sep 11, 2021 at 02:30:10PM -0400, Juancarlo Añez wrote:
> *invariant* cond: etc
A software invariant is still an assertion.
In another post, I semi-suggested a new (soft) keyword:
unless condition:
# block
raise Exception
But really, it's just an "if not".
if
On Fri, Sep 10, 2021 at 06:48:42PM -0400, Juancarlo Añez wrote:
> I agree that assertions can be and are abused.
>
> And I'm not too interested in DBC, nor in preconditions, nor in contracts.
In your first post you said:
[quote]
This is in the context of "Design by contrast" (DBC) as a useful
I really don't get what you hope for. The 'raise' statement already exists
in Python. I don't need a different way to spell that. So does 'if'.
On Sat, Sep 11, 2021, 2:37 PM Juancarlo Añez wrote:
> David,
>
> It seems I didn't state clearly enough my original statement, which is
> that software
David,
It seems I didn't state clearly enough my original statement, which is that
software will *_always_ *fail, even because of faulty hardware components,
or cosmic rays.
For software to be resilient, it must assert it's expected state.
But that doesn't have to be with the *assert*
Marc-Andre,
I must agree that the current state of assertions with "-O" and "-OO" is
difficult to impossible to change.
Perhaps I'm looking for an:
*invariant* cond: etc
Regards,
On Sat, Sep 11, 2021 at 11:00 AM Marc-Andre Lemburg wrote:
> On 11.09.2021 15:17, Juancarlo Añez wrote:
> > Of
On Sat, Sep 11, 2021 at 9:20 AM Juancarlo Añez wrote:
> I'm happy about dropping the DBC theme and rebooting to make *assert* easier
> to use so it gets used more.
>
I agree with Steven, Marc-Andé, and others in seeing "using assertions
more" as an anti-goal.
This isn't to say that a given
On 11.09.2021 15:17, Juancarlo Añez wrote:
> Of course, none of this will make sense to programmers with a strong belief
> that
> assertions must always be turned off in production runs.
You seem to be missing that the Python optimize mode turns off
all code which is related to debugging
It's fair to note that complex arguments to assertions can be hacked with:
*assert* cond, (
f'{conputesomething} {and more}'
f''{some more}'
)
The exception type can't be changed, though.
On Sat, Sep 11, 2021 at 9:17 AM Juancarlo Añez wrote:
> Stephen,
>
> Assertions have their
Stephen,
Assertions have their roots in mathematics, as does most everything in
programming languages.
I'm happy about dropping the DBC theme and rebooting to make *assert* easier
to use so it gets used more.
I liked the suggestion of:
*assert *cond:
# prepare failure information
Juancarlo A$(D+P(Bez writes:
> 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.
The
On 10/09/2021 23:38, Juancarlo Añez wrote:
Following with the ideas on this thread, it would be possible for -OO
to turn off only assertions with exceptions that descend from
AssertionError.
I think this would be confusing, as contrasted with the simple rule that
-OO turns off
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 wrote:
> On
Christopher,
The *if* version has the condition inverted, and it's structure makes it
look as part of the algorithm, instead of an assertion over an invariant.
Following with the ideas on this thread, it would be possible for -OO to
turn off only assertions with exceptions that descend from
On 10.09.2021 05:49, Steven D'Aprano wrote:
> What I question is that allowing assert to raise non-assertions will
> lead to *more* resilient software rather than less.
>
> I know far too many people who insist on abusing assertions as a lazy
> way to validate caller- or user-supplied data,
And 4) DBC constraints also become more useful than standard assertions
when used in the context of a class hierarchy.
I.e. preconditions, postconditions and invariants should be stronger (or
sometimes weaker, IIRC, there are subtle rules related to variance and
contravariance) for subclasses
On Fri, Sep 10, 2021 at 7:30 AM Steven D'Aprano wrote:
>
> [...] If we are seriously considering DBC for Python, [...]
As I think I wrote in the previous thread about DBC in Python, there are
already several DBC libraries on PyPI and we should precisely evaluate both
their design and impact
On Thu, Sep 09, 2021 at 09:16:23AM -0700, Guido van Rossum wrote:
> assert cond, raise=ExcType(args)
How about this?
if not cond: raise ExcType(args)
This is 100% backwards compatible, doesn't not abuse `assert`, will not
be removed when running under -O, and takes exactly the same
On Thu, Sep 09, 2021 at 12:53:34PM -0400, Ricky Teachey wrote:
> I have never heard of DBC and don't have a clue what is stands for. I am
> not a pro software developer.
DBC stands for "Design By Contract", it is a methodology for developing
software.
On Thu, Sep 09, 2021 at 12:02:13PM -0400, Juancarlo Añez wrote:
> Steven,
>
> The purpose is to make it easier to make software more resilient.
Thank you but I understand the purpose of DBC and how it can be helpful
for writing resilient software. If you search the archives, you will see
that
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
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
On Thu, Sep 9, 2021 at 12:38 PM Christopher Barker
wrote:
> Take a look at the archives of this list -- there was a large
> conversation about DBC a while back (a year, two years ??? )
>
> I think if you really want to support DBC, there will need to be more
> changes than this -- though there
Take a look at the archives of this list -- there was a large
conversation about DBC a while back (a year, two years ??? )
I think if you really want to support DBC, there will need to be more
changes than this -- though there are libraries that support it with
current Python.
Also, let's be
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
Let me re-*assert* ;-)
External tests will not be invoked at runtime, yet failures *_will_* occur
at runtime because of a variety of environmental factors (including cosmic
rays).
Software should assert at least some of its preconditions, postconditions,
and invariants.
How can we make that
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
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
On Tue, Sep 7, 2021 at 8:37 AM Simão Afonso <
simao.afo...@powertools-tech.com> wrote:
> On 2021-09-07 11:12:37, Juancarlo Añez wrote:
> > Basically, the proposal is to allow for an exception type and value to be
> > specified in *assert*, instead of the customary:
> >
> > if not assertion:
> >
On 2021-09-07 11:12:37, Juancarlo Añez wrote:
> Basically, the proposal is to allow for an exception type and value to be
> specified in *assert*, instead of the customary:
>
> if not assertion:
>
> raise ValueError('a message')
What's wrong with:
> if __debug__:
> if not assertion:
>
31 matches
Mail list logo
