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

[Chris Angelico]

On Wed, Sep 26, 2018 at 7:59 AM Kyle Lahnakoski <klahnakoski at mozilla.com> wrote:
> I use DbC occasionally to clarify my thoughts during a refactoring, and then only in the places that continue to make mistakes. In general, I am not in a domain that benefits from DbC.
>
> Contracts are code: More code means more bugs.

Contracts are executable documentation. If you can lift them directly
into user-readable documentation (and by "user" here I mean the user
of a library), they can save you the work of keeping your
documentation accurate.

> This contract does not help me:
>
> What is_absolute()?  is "file:///" absolute?

I'd have to assume that is_absolute() is defined elsewhere. Which
means that the value of this contract depends entirely on having other
functions, probably ALSO contractually-defined, to explain it.

> How does this code fail?
> What does a permission access problem look like?

Probably an exception. This is Python code, and I would generally
assume that problems are reported as exceptions.

> Can initial_paths can be None?

This can be answered from the type declaration. It doesn't say
Optional, so no, it can't be None.

> Can initial_paths be files? directories?

Presumably not a question you'd get if you were actually using it; the
point of the function is to "[r]esolve the initial paths of the
dependency graph by recursively adding *.py files beneath given
directories", so you'd call it because you have directories and want
files back.

> What are the side effects?

Hopefully none, other than the normal implications of hitting the file system.

It's easy to show beautiful examples that may actually depend on other
things. Whether that's representative of all contracts is another
question.

ChrisA