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 <apal...@gmail.com> wrote:
> 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*
>
--
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/BUX2AHAJRPKOX2MTNEK4IOP5V3TH7JJW/
Code of Conduct: http://python.org/psf/codeofconduct/
