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

[Marko Ristin-Kaufmann]

Hi Paul,
Quite a few people replied on this thread and the previous one before the
fork that dbc is either useless in Python or at best useful in
avionics/niche applications.

I'm really only saying that contracts are a superior (complementary) tool
to informal documentation, doctests, reading the implementation, reading
the tests and trial-and-error.

For every library that have the contracts which can be written down
formally in a pragmatic way, and when the users of the library are multiple
-- then these libraries would benefit from dbc.

That's all that I'm saying and it might have come over as arrogant due to
limits of the medium. It was not my intention to sound so.

I'll have a look at pathlib then.

Cheers,
Marko



Le mer. 26 sept. 2018 à 15:15, Paul Moore <p.f.moore at gmail.com> a écrit :

> On Wed, 26 Sep 2018 at 14:04, Marko Ristin-Kaufmann
> <marko.ristin at gmail.com> wrote:
> >
> > @Chris Angelico  would annotating pathlib convince you that contracts
> are useful? Is it general enough to start with?
>
> Whoa - be careful here. No-one is saying that "contracts aren't
> useful" (at least not that I'd heard). We're saying that contracts
> *aren't a solution for every library in existence* (which was
> essentially your claim). Annotating pathlib can't convince anyone of
> that claim. At best (and this is all that I'm imagining) it might give
> some indication of why you have such an apparently-unreasonable level
> of confidence in contracts.
>
> I do not expect *ever* to believe you when you say that all projects
> would benefit from contracts. What I might get from such an exercise
> is a better understanding of what you're imagining when you talk about
> a real project "using contracts". Best case scenario - I might be
> persuaded to use them occasionally. Worst case scenario - I find them
> distracting and unhelpful, and we agree to differ on their value.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180926/ecaba622/attachment.html>