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

Paul Moore p.f.moore at gmail.com
Fri Sep 28 05:44:16 EDT 2018

On Fri, 28 Sep 2018 at 10:37, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Sep 28, 2018 at 7:29 PM Jonathan Fine <jfine2358 at gmail.com> wrote:
> >
> > I like this discussion. I'd like to add another theme, namely what
> > should happen when there is an error. (This is prompted by race
> > hazards when performing file system operations.)
> >
> > Suppose fn_a() calls fn_b(), and fn_b() raises an exception. What then
> > should fn_a() do? It may be that this exception has left part or all
> > of the system in an inconsistent (invalid) state.
> That's why try/finally exists. You shouldn't have to worry about
> contracts for that.
> (Similarly, context managers, which are a way of wrapping up
> try/finally into a convenient package.)

However, a contract would need to be able to express "Returns a fully
initialised widget or raises a BrokenWidget exception". Unit tests do
this sort of thing all the time.


More information about the Python-ideas mailing list