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.mo...@gmail.com> a écrit : > On Thu, 27 Sep 2018 at 08:03, Greg Ewing <greg.ew...@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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
