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

[Paul Moore]

On Thu, 27 Sep 2018 at 08:03, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> David Mertz wrote:
> > the reality is that they really ARE NOT much different
> > from assertions, in either practice or theory.
>
> Seems to me that assertions is exactly what they are. Eiffel just
> provides some syntactic sugar for dealing with inheritance, etc.
> You can get the same effect in present-day Python if you're
> willing to write the appropriate code.

Assertions, as far as I can see, are the underlying low level
*mechanism* that contracts would use. Just like they are the low level
mechanism behind unit tests (yeah, it's really exceptions, but close
enough). But like unit tests, contracts seem to me to be a philosophy
and a library / programming technique layered on top of that base. The
problem seems to me to be that DbC proponents tend to evangelise the
philosophy, and ignore requests to show the implementation (often
pointing to Eiffel as an "example" rather than offering something
appropriate to the language at hand). IMO, people don't tend to
emphasise the "D" in DbC enough - it's a *design* approach, and more
useful in that context than as a programming construct.

For me, the philosophy seems like a reasonable way of thinking, but
pretty old hat (I learned about invariants and pre-/post-conditions
and their advantages for design when coding in PL/1 in the 1980's,
about the same time as I was learning Jackson Structured Programming).
I don't think in terms of contracts as often as I should - but it's
unit tests that make me remember to do so. Would a dedicated
"contracts" library help? Probably not much, but maybe (if it were
lightweight enough) I could get used to the idea.

Like David, I find that having contracts inline is the biggest problem
with them. I try to keep my function definitions short, and contracts
can easily add 100% overhead in terms of lines of code. I'd much
prefer contracts to be in a separate file. (Which is basically what
unit tests written with DbC as a principle in mind would be). If I
have a function definition that's long enough to benefit from
contracts, I'd usually think "I should refactor this" rather than "I
should add contracts".

Paul