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

Marko Ristin-Kaufmann marko.ristin at gmail.com
Thu Sep 13 18:24:11 EDT 2018

A brief follow-up (latest version 1.5.3): I removed the dependency on meta
package so that now all comprehensions and generator expressions work. I
still had to depend on asttokens in order to get the source code of the
condition function. Is there maybe an alternative solution which uses only
standard libraries?

Any thoughts or feedback on the icontract library in general?


On Mon, 10 Sep 2018 at 09:29, Marko Ristin-Kaufmann <marko.ristin at gmail.com>

> Hi,
> I implemented the inheritance via meta classes and function and class
> attributes for pre/postconditions and invariants, respectively. Unless I
> missed something, this is as far as we can go without the proper language
> support with a library based on decorators:
> https://github.com/Parquery/icontract (version 1.5.0)
>  Note that it is actually a complete implementation of design-by-contract
> that supports both weakening of the preconditions and strengthening of the
> postconditions and invariants.
> Could you please have a look and let me know what you think about the
> current implementation?
> Once we are sure that there is nothing obvious missing, I'd like to move
> forward and discuss whether we could add this library (or rewrite it) into
> the standard Python libraries and what needs to be all fixed till to make
> it that far.
> Cheers,
> Marko
> On Sat, 8 Sep 2018 at 21:34, Jonathan Fine <jfine2358 at gmail.com> wrote:
>> Michel Desmoulin wrote:
>> > Isn't the purpose of "assert" to be able to do design by contract ?
>> >
>> >     assert test, "error message is the test fail"
>> >
>> > I mean, you just write your test, dev get a feedback on problems, and
>> > prod can remove all assert using -o.
>> >
>> > What more do you need ?
>> Good question. My opinion is that assert statements are good. I like them.
>> But wait, more is possible. Here are some ideas.
>> 1. Checking the return value (or exception). This is a post-condition.
>> 2. Checking return value, knowing the input values. This is a more
>> sophisticated post-condition.
>> 3. Adding checks around an untrusted function - possibly third party,
>> possibly written in C.
>> 4. Selective turning on and off of checking.
>> The last two, selective checks around untrusted functions, I find
>> particularly interesting.
>> Suppose you have a solid, trusted, well-tested and reliable system.
>> And you add, or change, a function called wibble(). In this situation,
>> errors are most likely to be in wibble(), or in the interface to
>> wibble().
>> So which checks are most valuable? I suggest the answer is
>> 1. Checks internal to wibble.
>> 2. Pre-conditions and post-conditions for wibble
>> 3. Pre-conditions for any function called by wibble.
>> Suppose wibble calls wobble. We should certainly have the system check
>> wobble's preconditions, in this situation. But we don't need wobble to
>> run checks all the time. Only when the immediate caller is wibble.
>> I think assertions and design-by-contract point in similar directions.
>> But design-by-contract takes you further, and is I suspect more
>> valuable when the system being built is large.
>> Thank you, Michel, for your good question.
>> --
>> Jonathan
>> _______________________________________________
>> 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/20180914/b93c7c25/attachment.html>

More information about the Python-ideas mailing list