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.
Cheers, Marko
Le jeu. 27 sept. 2018 à 10:43, Paul Moore p.f.moore@gmail.com a écrit :
On Thu, 27 Sep 2018 at 08:03, Greg Ewing greg.ewing@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/