[Python-ideas] Pre-conditions and post-conditions

Wes Turner wes.turner at gmail.com
Mon Aug 27 11:01:21 EDT 2018


Runtime checks: data validation & code validation
Compile-time checks: code validation

What sort of data validation is appropriate for assert statements or
contacts that may be skipped due to trading performance for more risk
('optimized out')?
Checking the value of a Number?
Checking that a large graph has no cycles?
Checking that a database table exists and has the appropriate relations and
constraints?

assert statements are skipped at runtime with -O and -OO whether or not
they're in [reorderable] aspects applied with decorators, at the beginning
or end of a function, or in methods named something like setUp and tearDown.

https://docs.python.org/3/using/cmdline.html#envvar-PYTHONOPTIMIZE
https://docs.python.org/3/using/cmdline.html#cmdoption-o


> -O
>   Remove assert statements and any code conditional on the value of
__debug__


> PYTHONOPTIMIZE
>   If this is set to a non-empty string it is equivalent to specifying the
-O option. If set to an integer, it is equivalent to specifying -O multiple
times.


On Monday, August 27, 2018, Steven D'Aprano <steve at pearwood.info> wrote:

> On Mon, Aug 27, 2018 at 11:00:22PM +1000, Chris Angelico wrote:
>
> > Sometimes "type" doesn't mean the same thing to the language and to
> > the human. Suppose you're trying to create a Python script that
> > replicates a C program; you might want to declare that a variable is
> > not of type "integer" but type "32-bit unsigned integer", with
> > wrap-around. Or, wording it another way: "integer modulo 2**32". Is
> > that an assertion of type, or of type and value? As a precondition to
> > a function, requiring that a parameter be an integer no less than zero
> > and no greater than 4294967295 is, in a sense, checking its type and
> > its value; but it's kinda just asserting its type.
>
> It is making an assertion about the value of an instance of type "int".
> Its not a separate type requiring an explicit coercion or cast. Its just
> a non-negative int less than 2**32.
>
> If the compiler supports the concept of a 32-bit unsigned integer type,
> then of course we can change our implementation to use that type instead
> of our regular ints. But we can't expect to pass such a 32-bit unsigned
> integer to a function which expects a regular int unless they are
> duck-type compatible, or the compiler performs automatic coercions.
> (So-called "weak typing").
>
> A better example is the one I gave earlier, of a graph with no cycles.
> There is a deep fundamental difference between a *statically checked*
> DAG with no cycles (a graph which can never contain a cycle because the
> compiler won't let you create one) and a *dynamically checked* DAG that
> merely has no cycles *now* (it may have had cycles earlier, and it might
> have cycles later, but right now it has none).
>
> These are very different semantics, and Eiffel's contracts support the
> second kind: runtime value checks.
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180827/528552a1/attachment.html>


More information about the Python-ideas mailing list