[Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Fri, Sep 28, 2018 at 11:25 AM Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
>
> Hi,
>
> I annotated pathlib with contracts:https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML docs into https://github.com/mristin/icontract-pathlib-poc/blob/master/contracts-pathlib-poc.zip, you can just unpack and view the index.html.
>
> One thing I did observe was that there were contracts written in text all over the documentation -- I tried to formulate most of them in code. Since I'm not the implementer nor very familiar with the module, please consider that many of these contracts can be definitely made more beautiful. There were some limitations to icontract-sphinx extension and icontracts which I noted at the top of the document.
>

You do a lot of contracts that involve is_absolute and other checks.
But the postcondition on is_absolute merely says:

not result or self.root != ""

(Also: I'm not sure, but I think maybe that should be _root?? Leaving
that aside.)

So I'm not sure how much you can really ascertain about absolute
paths. You guarantee that is_absolute will return something plausible,
but unless you guarantee that it's returning the correct value,
depending on it for your preconditions seems dubious. A buggy
is_absolute could break basically everything, and your contracts
wouldn't notice.

It is still fundamentally difficult to make assertions about the file
system as pre/post contracts. Are you becoming aware of this?
Contracts, as has been stated multiple times, look great for
mathematically pure functions that have no state outside of their own
parameters and return values (and 'self', where applicable), but are
just poor versions of unit tests when there's anything external to
consider.

ChrisA