Clarity vs. code reuse/generality
charles at declareSub.com
Fri Jul 10 18:27:25 CEST 2009
On Jul 9, 2009, at 10:57 PM, Steven D'Aprano wrote:
> On Fri, 10 Jul 2009 03:28:04 +0100, Nobody wrote:
>> On Thu, 09 Jul 2009 04:57:15 -0300, Gabriel Genellina wrote:
>>> Nobody says you shouldn't check your data. Only that "assert" is not
>>> the right way to do that.
>> "assert" is not the right way to check your *inputs*. It's a
>> reasonable way to check data which "should" be valid, as well as a
>> to document what variables are supposed to contain.
> Where are those variables coming from?
> The distinction really boils down to this:
> * asserts should never fail. If there is any chance that an assertion
> might fail outside of test suites, then don't use assert.
> You can't control what input the caller provides to a function, so
> the data is generated inside the function, a caller might provide
> something unexpected. Therefore, assert is inappropriate for checking
> function parameters, even if that function is "private" and only
> by your own functions.
> (1) So-called "private" or "internal" functions have a habit of
> public, and then you have asserts in public functions.
> (2) If public() calls _private(x), and _private uses assert to check
> value of x, there is a risk that if public() is buggy and supplies an
> invalid x, the assertion will never be checked and _private() will
> incorrect results.
> (3) assert is absolutely unsuitable for enforcing pre-conditions and
> conditions, unless such conditions are mere "guidelines", because
> can be switched off at runtime.
Unless, of course, you want to switch off such checking at runtime, as
you might when using a design-by-contract approach.
More information about the Python-list