[Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano <steve at pearwood.info> wrote:
>
> On Mon, Oct 08, 2018 at 09:32:23PM +1100, Chris Angelico wrote:
> > On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano <steve at pearwood.info> wrote:
> > > > In other words, you change the *public interface* of your functions
> > > > all the time? How do you not have massive breakage all the time?
> > >
> > > I can't comment about Marko's actual use-case, but *in general*
> > > contracts are aimed at application *internal* interfaces, not so much
> > > library *public* interfaces.
> >
> > Yet we keep having use-cases shown to us involving one person with one
> > module, and another person with another module, and the interaction
> > between the two.
>
> Do we? I haven't noticed anything that matches that description,
> although I admit I haven't read every single post in these threads
> religiously.

Try this:

On Mon, Oct 8, 2018 at 5:11 PM Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
> Alice tests her package A with some test data D_A. Now assume Betty did not write any contracts for her package B. When Alice tests her package, she is actually making an integration test. While she controls the inputs to B from A, she can only observe the results from B, but not whether they are correct by coincidence or B did its job correctly. Let's denote D'_B the data that is given to B from her original test data D_A during Alice's integration testing.
>

If you're regularly changing your function contracts, such that you
need to continually test  in case something in the other package
changed, then yes, that's exactly what I'm talking about.

I'm tired of debating this. Have fun. If you love contracts so much,
marry them. I'm not interested in using them, because nothing in any
of these threads has shown me any good use-cases that aren't just
highlighting bad coding practices.

ChrisA