[Python-ideas] Pre-conditions and post-conditions

[Marko Ristin-Kaufmann]

Hi,
I think we got entangled in a discussion about whether design-by-contract
is useful or not. IMO, the personal experience ("I never used/needed this
feature") is quite an inappropriate rule whether something needs to be
introduced into the language or not.

There seems to be evidence that design-by-contract is useful. Let me cite
Bertrand Meyer from his article "Why not program right?" that I already
mentioned before:

> We are back then to the core question. These techniques are simple,
> demonstrably useful, practical, validated by years of use, explained in
> professional books (e.g. [6]), introductory programming textbooks (e.g.
> [7]), EdX MOOCs (e.g. [8]), YouTube videos, online tutorials at eiffel.org,
> and hundreds of articles cited thousands of times.
>
6.    Bertrand Meyer, Object-Oriented Software Construction, 2nd edition,
> Prentice Hall, 1997.
>
> 7.    Bertrand Meyer, Touch of Class: Learning to Program Well Using
> Objects and Contracts, Springer, 2009, see touch.ethz.ch and Amazon page
> <https://www.amazon.com/Touch-Class-Learning-Program-Contracts/dp/3540921443>
> .
>
> 8.    MOOCs (online courses) on EdX : "Computer: Art, Magic, Science", Part
> 1 <https://www.edx.org/course/computing-art-magic-science-ethx-cams-2x>
> and Part 2
> <https://www.edx.org/course/computing-art-magic-science-part-ii-ethx-cams-ii-x>.
> (Go to "archived versions" to follow the courses.)
>
Is there any logical or empirical objection that the design-by-contract is
not useful and hence does not merit to be introduced into the core
language? There is little point in writing a PEP and fleshing out the
details if the community will reject it on grounds that design-by-contract
by itself is meaningless. So I'd suggest we clarify this first before we
move on.

@David Mertz:

> Nonetheless, I'll say that it's really not hard to get a decorator to
> cooperate with inheritance if you want that. If you decorate a parent class
> you can simply attach the collection of invariants to the class as
> notations, along with whatever actual guards the decorator enforces. An
> inheriting child (also decorated) can just look up those notations and
> apply them to the child.
>
> I.e. the first thing a decorator can do is lookup the invariants attached
> to the parent (if any) and apply them to the child (if this behavior is
> enabled). Easy peasy.
>

Could you please elaborate a bit? I don't see how the annotations would
make the contracts invoked on inheritance. Consider this simple case:

class A:
    @icontract.pre(lambda x: x > 0)
    def some_method(self, x: int)->None:
        pass

class B(A):
    # Precondition should be inherited here.
    def some_method(self, x: int) -> None:
        pass

You would still need to somehow decorate manually the overridden methods
even though you would not specify any new contracts, right? Is there a
mechanism in Python that I am not aware of that would allow us to
accomplish that?

On Wed, 29 Aug 2018 at 22:41, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Jonathan Fine wrote:
> >
> > My message of support for Ivan quoted the Eiffel docs.
> >
> >>
> https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions
> >
> >>During development and testing, assertion monitoring should
> >>be turned on at the highest possible level. Combined with
> >>static typing and the immediate feedback of compilation techniques
> >>[...] this permits the development process  [...]
> >>where errors are exterminated at birth.
>
> I think you're misinterpreting the Eiffel docs here. It's saying
> that contracts *together* with static typing help to catch a lot
> of errors early in the development process. It's not saying that
> contracts are verified statically, or that all the errors thus
> caught are caught at compile time.
>
> > the context to me makes it clear
> > that in Eiffel static typing IS NOT regarded as a run-time assertion.
>
> That's true, but static typing and contracts are *different things*
> in Eiffel. Static types are checked at compile time, contracts
> are checked at run time.
>
> --
> Greg
> _______________________________________________
> 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/20180830/a1d0c413/attachment-0001.html>