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
10 matches
Mail list logo
