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.ew...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/