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
*raise *ExType(args)
Because the current:
*assert *cond, arg
Will always raise AssertionError, and do a str(arg), which means that
*arg* must
be simple, or rely on a function that creates more complex reporting.
It think it would be fine if ExtType->AssertionError is enforced. Then
there could be a hierarchy of AssertionError depending on the type of
problem or its severity.
Of course, none of this will make sense to programmers with a strong belief
that assertions must always be turned off in production runs.
I, on the other hand, believe that any complex computation or algorithm
should assert its expected state and abort if the expectations are not met,
even when the reason for the failure is unknown. Think about financial,
insurance, transportation, or medical algorithms.
By epistemological reasons a failure caused by a bug is almost
*_always_* unexpected,
and the reasons for the failure are unknown at runtime (a shorter version
is that "programmers don't write bugs on purpose, so bugs are always
unforseen").
On Sat, Sep 11, 2021 at 12:32 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Juancarlo A�+Pez 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 more I see this elaborated, the less I like it. "assert" has a
> traditional meaning in programming, which is only a slight extension
> on the English meaning (that you can turn the check off for
> performance).
>
> Although the idea that assert could be the fundamental building block
> for design-by-contract (DBC), to my mind this has three problems.
>
> (1) You're coopting a keyword that has a consistent established
> meaning in English, in programming languages in general, and in
> Python, and changing that meaning.
>
> (2) I doubt that "assert" alone is sufficient for DBC. In practice,
> you'll want a more expressive, larger vocabulary. It's not clear
> that *any* of that vocabulary is best expressed by "assert" at
> this point. If not, why mess with what works?
>
> (3) There's a subtle difference between an assertion and a contract.
> An assertion is a statement of fact: it's either right or it's
> wrong. But the whole point of contracts in the real world is that
> they are constraints on behavior to be enforced. The assumption
> is that it's possible to be in violation of the contract. The
> point of *asserting* something is that you believe it's absolutely
> true, there's no point in going on if it's false. You have to
> start over.
>
> A presumption that violation is possible may not be true of the
> contracts in DBC, I don't know. But I would prefer not to mix the
> difficulties of the semantics of "contract" with the simplicity of
> the semantics of "assert".
>
> Steve
>
>
--
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/2EETNAKNLL3U3IMCHCYTWR7G5XA2NIUL/
Code of Conduct: http://python.org/psf/codeofconduct/
