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

[Greg Ewing]

Chris Angelico wrote:
> For example, matplotlib's
> plt.show() method guarantees that... a plot will be shown, and the
> user will have dismissed it, before it returns. Unless you're inside
> Jupyter/iPython, in which case it's different. Or if you're in certain
> other environments, in which case it's different again. How do you
> define the contract for something that is fundamentally interactive?

Indeed, this is what bothers me about DbC fanaticism. It seems to
have been conceived by people thinking about very computer-sciency
kinds of problems, e.g. you're implenenting a data structure which
has certain important invariants that can be expressed mathematically,
and code can be written that checks them reasonably efficiently.
All very neat and self-contained.

But a lot of real-world code isn't like that -- much of the time,
the correctness of a piece of code can't be tested without reference
to things outside that piece of code, or even outside of the program
altogether. How would you write DbC contracts for a GUI, for
example? Most of the postconditions consist of "an image looking
something like this appears on the screen", where "this" is a very
complicated function of the previous state of the system and the
user's input.

IMO, the reason DbC hasn't taken off is that it assumes an idealised
model of what programming consists of that doesn't match reality
well enough.

-- 
Greg