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

Marko Ristin-Kaufmann marko.ristin at gmail.com
Thu Sep 27 05:37:10 EDT 2018

Hi Paul,
I only had a contracts library in mind (standardized so that different
modules with contracts can interact and that the ecosystem for automic
testing could emerge). I was never thinking about the philosophy or design
methodology (where you write _all_ the contracts first and then have the
implementation fulfill them). I should have clarified that more. I
personally also don't think that such a methodology is practical.

I really see contracts as verifiable docs that rot less fast than human
text and are formally precise / less unambiguous than human text. Other
aspects such as deeper tests and hand-braking (e.g., as postconditions
which can't be practically implemented in python without exit stack context
manager) are also nice to have.

I should be done with pathlib contracts by tonight if I manage to find some
spare time in the evening.


Le jeu. 27 sept. 2018 à 10:43, Paul Moore <p.f.moore at gmail.com> a écrit :

> On Thu, 27 Sep 2018 at 08:03, Greg Ewing <greg.ewing at canterbury.ac.nz>
> wrote:
> >
> > David Mertz wrote:
> > > the reality is that they really ARE NOT much different
> > > from assertions, in either practice or theory.
> >
> > Seems to me that assertions is exactly what they are. Eiffel just
> > provides some syntactic sugar for dealing with inheritance, etc.
> > You can get the same effect in present-day Python if you're
> > willing to write the appropriate code.
> Assertions, as far as I can see, are the underlying low level
> *mechanism* that contracts would use. Just like they are the low level
> mechanism behind unit tests (yeah, it's really exceptions, but close
> enough). But like unit tests, contracts seem to me to be a philosophy
> and a library / programming technique layered on top of that base. The
> problem seems to me to be that DbC proponents tend to evangelise the
> philosophy, and ignore requests to show the implementation (often
> pointing to Eiffel as an "example" rather than offering something
> appropriate to the language at hand). IMO, people don't tend to
> emphasise the "D" in DbC enough - it's a *design* approach, and more
> useful in that context than as a programming construct.
> For me, the philosophy seems like a reasonable way of thinking, but
> pretty old hat (I learned about invariants and pre-/post-conditions
> and their advantages for design when coding in PL/1 in the 1980's,
> about the same time as I was learning Jackson Structured Programming).
> I don't think in terms of contracts as often as I should - but it's
> unit tests that make me remember to do so. Would a dedicated
> "contracts" library help? Probably not much, but maybe (if it were
> lightweight enough) I could get used to the idea.
> Like David, I find that having contracts inline is the biggest problem
> with them. I try to keep my function definitions short, and contracts
> can easily add 100% overhead in terms of lines of code. I'd much
> prefer contracts to be in a separate file. (Which is basically what
> unit tests written with DbC as a principle in mind would be). If I
> have a function definition that's long enough to benefit from
> contracts, I'd usually think "I should refactor this" rather than "I
> should add contracts".
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180927/0ca13a04/attachment-0001.html>

More information about the Python-ideas mailing list