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

Kyle Lahnakoski klahnakoski at mozilla.com
Tue Sep 25 17:58:36 EDT 2018

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. Declarative contracts are
succinct, but difficult to debug when wrong; I believe this because the
debugger support for contracts is poor; There is no way to step through
the logic and see the intermediate reasoning in complex contracts.  A
contract is an incomplete duplication of what the code already does: at
some level of complexity I prefer to use a duplicate independent
implementation and compare inputs/outputs.

Writing contracts cost time and money; and that cost should be weighed
against the number and flexibility of the customers that use the code. 
A one-time script, a webapp for you team, an Android app for your
startup, fraud software, and Facebook make different accounting
decisions.  I contend most code projects can not justify DbC.

On 2018-09-24 03:46, Marko Ristin-Kaufmann wrote:
> When you are documenting a method you have the following options:
> 1) Write preconditions and postconditions formally and include them
> automatically in the documentation (/e.g., /by using icontract library).
> 2) Write precondtions and postconditions in docstring of the method as
> human text.
> 3) Write doctests in the docstring of the method.
> 4) Expect the user to read the actual implementation.
> 5) Expect the user to read the testing code.

There are other ways to communicate how a method works.

6) The name of the method
7) How the method is called throughout the codebase
8) observing input and output values during debugging
9) observing input and output values in production
10) relying on convention inside, and outside, the application
11) Don't communicate - Sometimes <complexity>/<num_customers> is too
high; code is not repaired, only replaced.

> This is again something that eludes me and I would be really thankful
> if you could clarify. Please consider for an example, pypackagery
> (https://pypackagery.readthedocs.io/en/latest/packagery.html) and the
> documentation of its function resolve_initial_paths:
> |packagery.||resolve_initial_paths|(/initial_paths/)
>     Resolve the initial paths of the dependency graph by recursively
>     adding |*.py| files beneath given directories.
>     Parameters: 	
>     *initial_paths* (|List|[|Path|]) – initial paths as absolute paths
>     Return type: 	
>     |List|[|Path|]
>     Returns: 	
>     list of initial files (/i.e./ no directories)
>     Requires: 	
>       * |all(pth.is_absolute() for pth in initial_paths)|
>     Ensures: 	
>       * |len(result) >= len(initial_paths) if initial_paths else
>         result == []|
>       * |all(pth.is_absolute() for pth in result)|
>       * |all(pth.is_file() for pth in result)|
> How is this difficult to read,[...]?

This contract does not help me: 

    Does it work on Windows?
    What is_absolute()?  is "file:///" absolute?
    How does this code fail? 
    What does a permission access problem look like? 
    Can initial_paths can be None?
    Can initial_paths be files? directories? 
    What are the side effects?

resolve_initial_path() is a piece code is better understood by looking
at the callers (#7), or not exposing it publicly (#11).  You can also
use a different set of abstractions, to make the code easier to read: 
UNION(file for p in initial_paths for file in p.leaves() if

At a high level, I can see the allure of DbC:  Programming can be a
craft, and a person can derive deep personal satisfaction from
perfecting the code they work on. DbC provides you with more decoration,
more elaboration, more ornamentation, more control.  This is not bad,
but I see all your arguments as personal ascetic sense.  DbC is only
appealing under certain accounting rules.  Please consider the
possibility that "the best code" is: low $$$, buggy, full of tangles,
and mostly gets the job done.   :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180925/259b005e/attachment-0001.html>

More information about the Python-ideas mailing list