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

Chris Angelico rosuav at gmail.com
Wed Sep 26 04:44:24 EDT 2018

On Wed, Sep 26, 2018 at 6:36 PM Paul Moore <p.f.moore at gmail.com> wrote:
> On Wed, 26 Sep 2018 at 06:41, Chris Angelico <rosuav at gmail.com> wrote:
> >
> > On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
> > <marko.ristin at gmail.com> wrote:
> > > * The contracts written in documentation as human text inevitably rot and they are much harder to maintain than automatically verified formal contracts.
> >
> > Agreed.
> Agreed, if contracts are automatically verified. But when runtime cost
> comes up, people suggest that contracts can be disabled in production
> code - which invalidates the "automatically verified" premise.

Even if they're only verified as a dedicated testing pass ("okay,
let's run the unit tests, let's run the contract verifier, let's run
the type checker, cool, we're good"), they're still better off than
unchecked comments/documentation in terms of code rot. That said,
though: the contract for a function and the documentation for the
function are inextricably linked *already*, and if you let your API
docs rot when you make changes that callers need to be aware of, you
have failed your callers. Wholesale use of contracts would not remove
the need for good documentation; what it might allow is easier version
compatibility testing. It gives you a somewhat automated (or at least
automatable) tool for checking if two similar libraries (eg version
X.Y and version X.Y-1) are compatible with your code. That would be of
some value, if it could be trusted; you could quickly run your code
through a checker and say "hey, tell me what the oldest version of
Python is that will run this", and get back a response without
actually running a gigantic test suite - since it could check based on
the *diffs* in the contracts rather than the contracts themselves. But
that would require a lot of support, all up and down the stack.


More information about the Python-ideas mailing list