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

[Hugh Fisher]

> Date: Mon, 24 Sep 2018 09:46:16 +0200
> From: Marko Ristin-Kaufmann <marko.ristin at gmail.com>
> To: Python-Ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Why is design-by-contracts not widely
>         adopted?
> Message-ID:
>         <CAGu4bVB4=Bou+DhoDzayx=i7eQ2Gr8KDDOFONeaB-Qvt8LZo2A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"

[munch]

> Their users would hugely benefit from a more mature
> and standardized contracts library with informative violation messages.

Will respond in another message, because it's a big topic.

> I really don't see how DbC has to do with duck typing (unless you reduce it
> to mere isinstance conditions, which would simply be a straw-man argument)
> -- could you please clarify?

I argue that Design by Contract doesn't make sense for Python and other
dynamically typed, duck typed languages because it's contrary to how the
language, and the programmer, expects to work.

In Python we can write something like:

def foo(x):
    x.bar(y)

What's the type of x? What's the type of y? What is the contract of bar?
Don't know, don't care. x, or y, can be an instance, a class, a module, a
proxy for a remote web service. The only "contract" is that object x will
respond to message bar that takes one argument. Object x, do whatever
you want with it.

And that's a feature, not a bug, not bad design. It follows Postel's Law
for Internet protocols of being liberal in what you accept. It follows the
Agile principle of valuing working software over comprehensive doco.
It allows software components to be glued together quickly and easily.

It's a style of programming that has been successful for many years,
not just in Python but also in Lisp and Smalltalk and Perl and JavaScript.
It works.

Not for everything. If I were writing the avionics control routines for a
helicopter gas turbine, I'd use formal notation and static type checking
and preconditions and whatnot. But I wouldn't be using Python either.

> As soon as you need to document your code, and
> this is what most modules have to do in teams of more than one person
> (especially so if you are developing a library for a wider audience), you
> need to write down the contracts. Please see above where I tried to
> explained  that 2-5) are inferior approaches to documenting contracts
> compared to 1).

You left off option 6), plain text. Comments. Docstrings. README files.
Web pages. Books. In my experience, this is what most people consider
documentation. A good book, a good blog post, can explain more about
how a library works and what the implementation requirements and
restrictions are than formal contract notation. In particular, contracts in
Eiffel don't explain *why* they're there.

As for 4) reading the code, why not? "Use the source, Luke" is now a
programming cliche because it works. It's particularly appropriate for
Python packages which are usually distributed in source form and, as
you yourself noted, easy to read.

-- 

        cheers,
        Hugh Fisher