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

[Chris Angelico]

On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
>
> Hi Chris,
>
>> An extraordinary claim is like "DbC can improve *every single project*
>> on PyPI". That requires a TON of proof. Obviously we won't quibble if
>> you can only demonstrate that 99.95% of them can be improved, but you
>> have to at least show that the bulk of them can.
>
>
> I tried to give the "proof" (not a formal one, though) in my previous message.

(Formal proof isn't necessary here; we say "extraordinary proof", but
it'd be more accurate to say "extraordinary evidence".)

> The assumptions are that:
> * There are always contracts, they can be either implicit or explicit. You need always to figure them out before you call a function or use its result.

Not all code has such contracts. You could argue that code which does
not is inferior to code which does, but not everything follows a
strictly-definable pattern.

> * Figuring out contracts by trial-and-error and reading the code (the implementation or the test code) is time consuming and hard.

Agreed.

> * The are tools for formal contracts.

That's the exact point you're trying to make, so it isn't evidence for
itself. Tools for formal contracts exist as third party in Python, and
if that were good enough for you, we wouldn't be discussing this.
There are no such tools in the standard library or language that make
formal contracts easy.

> * The contracts written in documentation as human text inevitably rot and they are much harder to maintain than automatically verified formal contracts.

Agreed.

> * The reader is familiar with formal statements, and hence reading formal statements is faster than reading the code or trial-and-error.

Disagreed. I would most certainly NOT assume that every reader knows
any particular syntax for such contracts. However, this is a weaker
point.

So I'll give you two and two halves for that. Good enough to make do.

> I then went on to show why I think, under these assumptions, that formal contracts are superior as a documentation tool and hence beneficial. Do you think that any of these assumptions are wrong? Is there a hole in my logical reasoning presented in my previous message? I would be very grateful for any pointers!
>
> If these assumptions hold and there is no mistake in my reasoning, wouldn't that qualify as a proof?
>

It certainly qualifies as proof that SOME code MAY benefit from
contracts. It does not reach the much higher bar to support the claim
that "there are X projects on PyPI and every single one of them would
benefit". For instance, would youtube-dl benefit from DbC? To most
people, it's an application, not a library. Even if you're invoking it
from within a Python script, it's usually easiest to use the main
entrypoint rather than delve into its internals. Case in point:

https://github.com/Rosuav/MegaClip/blob/master/megaclip.py#L71

It's actually easier to shell out to a subprocess than to call on
youtube-dl as a library. Would DbC benefit youtube-dl's internal
functions? Maybe, but that's for the youtube-dl people to decide; it
wouldn't in the slightest benefit my app.

You might argue that a large proportion of PyPI projects will be
"library-style" packages, where the main purpose is to export a bunch
of functions. But even then, I'm not certain that they'd all benefit
from DbC. Some would, and you've definitely made the case for that;
but I'm still -0.5 on adding anything of the sort to the stdlib, as I
don't yet see that *enough* projects would actually benefit.

People have said the same thing about type checking, too. Would
*every* project on PyPI benefit from MyPy's type checks? No. Syntax
for them was added, not because EVERYONE should use them, but  because
SOME will use them, and it's worth having some language support. You
would probably do better to argue along those lines than to try to
claim that every single project ought to be using contracts.

ChrisA