Clarity vs. code reuse/generality

[Simon Forman]

On Jul 4, 12:30 pm, kj <no.em... at please.post> wrote:
> In <mailman.2611.1246721197.8015.python-l... at python.org> "Pablo Torres N." <tn.pa... at gmail.com> writes:
>
>
>
> >On Sat, Jul 4, 2009 at 10:05, kj<no.em... at please.post> wrote:
> >>>http://docs.python.org/reference/simple_stmts.html#grammar-token-asse...
> >tmt
> >>>"The current code generator emits no code for an assert statement when op=
> >timization is requested at compile time."
>
> >> Sorry, this doesn't say anything like "don't use assertions to test
> >> argument values". =C2=A0I'm aware of the fact that assertions are silence=
> >d
> >> under certain circumstances. =C2=A0But where does the principle 1. in
> >> your first reply come from? =C2=A0I've never seen it before, and would
> >> like to understand the reasoning behind it.
>
> >> kj
> >> --
> >>http://mail.python.org/mailman/listinfo/python-list
>
> >But...if no code is generated for assertions on some occasions, then the
> >parameters would go unchecked, potentially breaking your code in said
> >occasions.
>
> This implies that code that uses *any* assert statement (other than
> perhaps the trivial and meaningless ones like "assert True") is
> liable to break, because whatever it is that these assert statements
> are checking "on some occasions, ... would go unchecked, potentially
> breaking your code."
>
> I'm beginning to think that the original "precept" was simply "cargo
> cult," i.e. one of those rules that are parroted without being
> fully understood.
>
> As I wrote in my original post, the function I posted was an internal
> ("helper") function, not to be used outside of the file.  This fact
> was further (ahem) underscored by the leading underscore in the
> function's name.  Under these circumstances, the assert statements
> seem to me perfectly in keeping with the intended use for them.
>
> kj

Assertions are for you, the programmer, to check that your
understanding of the code is correct (or not, i.e. if the assertion
fails.)

It's unfortunately not uncommon to see code where the assert statement
is used as an integral part of the processing, or, in other words,
where running the code with '-O' will cause changes in the way the it
runs.

In the code you posted, the assert statements seem to be checking that
other code/algorithms aren't (will never) pass that function "out of
bounds" arguments.  Perfectly valid IMO.  Since it's an internal
helper function you can (should) know that client code will /always/
call it with valid values, the asserts simply make your intuition or
knowledge explicit in a way that will show up dramatically if you're
wrong about that (i.e. if there's some problem elsewhere in the code
feeding that function.)

Assertions should never fail, which is why you can (or should be able
to without breaking your code) remove them entirely and know that your
program will run identically.  That's why folks are quick to jump on
cases where assertions are used as control-flow constructs.  (In your
function, however, they aren't.)

In a sense, assertions /are/ meaningless, except to the programmer.

FWIW, you can use "if __debug__:" and put anything you like in the
statement suite and the whole if statement goes away when run with '-
O'. Sort of a "super-assert".

Regards,
~Simon