On Jul 4, 12:30 pm, kj <no.em...@please.post> wrote: > In <mailman.2611.1246721197.8015.python-l...@python.org> "Pablo Torres N." > <tn.pa...@gmail.com> writes: > > > > >On Sat, Jul 4, 2009 at 10:05, kj<no.em...@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 -- http://mail.python.org/mailman/listinfo/python-list
