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 given
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 n
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* statement,
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 c
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 prog
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 (__debug
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 ro
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
*rai
10 matches
Mail list logo
