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

[Robert Collins]

On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
>
> Hi,
>
> Thank you for your replies, Hugh and David! Please let me address the points in serial.
>
> Obvious benefits
> You both seem to misconceive the contracts. The goal of the design-by-contract is not reduced to testing the correctness of the code, as I reiterated already a couple of times in the previous thread. The contracts document formally what the caller and the callee expect and need to satisfy when using a method, a function or a class. This is meant for a module that is used by multiple people which are not necessarily familiar with the code. They are not a niche. There are 150K projects on pypi.org. Each one of them would benefit if annotated with the contracts.

You'll lose folks attention very quickly when you try to tell folk
what they do and don't understand.

Claiming that DbC annotations will improve the documentation of every
single library on PyPI is an extraordinary claim, and such claims
require extraordinary proof.

I can think of many libraries where necessary pre and post conditions
(such as 'self is still locked') are going to be noisy, and at risk of
reducing comprehension if the DbC checks are used to enhance/extended
documentation.

Some of the examples you've been giving would be better expressed with
a more capable type system in my view (e.g. Rust's), but I have no
good idea about adding that into Python  :/.

Anyhow, the thing I value most about python is its pithyness: its
extremely compact, allowing great developer efficiency, but the cost
of testing is indeed excessive if the tests are not structured well.
That said, its possible to run test suites with 10's of thousands of
tests in only a few seconds, so there's plenty of headroom for most
projects.

-Rob