Why assert is not a function?

[Cameron Simpson]

On 12Mar2021 05:31, Chris Angelico <rosuav at gmail.com> wrote:
>On Fri, Mar 12, 2021 at 3:37 AM Serhiy Storchaka <storchaka at gmail.com> wrote:
>> assert(expensive_computation())
>
>Do you have any asserts like that, or is that a purely theoretical
>complaint? I have never once seen anything that costly - usually it'll
>be something like checking a length (and this isn't C's strlen, since
>Python can get lengths of all built-in types quickly), or some simple
>checks.

That's very much in the eye of the beholder. Usually my asserts are 
pretty cheap. But there are two scenarios where they accrue significant 
cost.

Scenario 1 is where I'm maintaining some data structure, possibly with 
fiddly corner cases. That associated class may have a self_check method 
to verify integrity, and that can land in an assertion. Potentially 
quite expensive.

Scenario 2 is the performance critical function which nonetheless is 
complicated (or just... long). I've written a few of these and littering 
the code with asserts becomes necessary to check correctness, 
particularly if you're modifying it. Not everything lends itself to unit 
tests - we often want to be assured of things in the middle of a 
process.

In scenario 2, each assert is pretty cheap, but their cumulative effect 
has a significant performance impact. Being able to turn them off 
altogether is a distinct real world win.

(To those crying "break it up", sometimes that is hard because of the 
embodied state, and sometimes that is unwanted because of the 
performance impact (function calls aren't free and neither is the 
packaging-into-parameters needed to turn an operation into a function 
call); for 99% of code both of these are cheap enough, but in this niche 
they're a problem.

>Having assert be a function would not make it much harder to get rid
>of. It would just make it harder to get the text.

Hah. I repeat my mention of the ycecream package - very neat!

Cheers,
Cameron Simpson <cs at cskk.id.au>