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/