[Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

[Marko Ristin-Kaufmann]

Hi Steve (Turnbull),

It sounds to me like the proof of the pudding for Python will be
> annotating the ABC module with contracts.  If that turns out to be a
> mostly fruitless exercise, it's hard to see how "real" contracts
> (vs. using asserts to "program in contracting style") are an important
> feature for Python in general.
>

Do you mean annotating an abstract class with contracts or annotating the
actual functions in abc module?

If you meant abstract classes in general, we do that for quite some time in
our code base and had no problems so far. icontract already supports
inheritance of contracts (as well as weakening/strengthening of the
contracts).

Inheriting of contracts also proved useful when you define an interface as
a group of functions together with the contracts. You define the functions
as an ABC with purely static methods (no state) and specify the contracts
in that abstract class. The concrete classes implement the static
functions, but don't need to repeat the contracts since they are inherited
from the abstract class. I can copy/paste from our code base if you are
interested.

Cheers,
Marko

On Mon, 1 Oct 2018 at 15:09, Stephen J. Turnbull <
turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:

> Elazar writes:
>  > On Sun, Sep 30, 2018, 15:12 Stephen J. Turnbull <
>  > turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
>
>  > > What does "inherited" mean?  Just that methods that are not overridden
>  > > retain their contracts?
>  >
>  > Contracts are attached to interfaces, not to specifications. So
>  > when you have abstract base class, it defines contracts, and
>  > implementing classes must adhere to these contracts - the can only
>  > strengthen it, not weaken it.
>
> Stated in words, it sounds very reasonable.
>
> Thinking about the implications for writing Python code, it sounds
> very constraining in the context of duck-typing.  Or, to give a
> contrapositive example, you can write few, if any, contracts for
> dunders beyond their signatures.  For example, len(x) + len(y) ==
> len(x + y) is not an invariant over the classes that define __len__
> (eg, set and dict, taking the "x + y" loosely for them).  Of course if
> you restrict to Sequence, you can impose that invariant.  The question
> is the balance.
>
> It sounds to me like the proof of the pudding for Python will be
> annotating the ABC module with contracts.  If that turns out to be a
> mostly fruitless exercise, it's hard to see how "real" contracts
> (vs. using asserts to "program in contracting style") are an important
> feature for Python in general.
>
> That said, given the passion of the proponents, if we can come up with
> an attractive style for implementing contracts without a language
> change, I'd be +0 at least for adding a module to the stdlib.  But
> this is a Python 3.9 project, given the state of the art.
>
>  > This is precisely like with types, since types are contracts (and
>  > vice versa, in a way).
>
> Not Python types (== classes), though.  As a constraint on behavior,
> subclassing is purely nominal, although Python deliberately makes it
> tedious to turn a subclass of str into a clone of int.
>
> Steve
> _______________________________________________
> 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/20181001/144f2671/attachment.html>