Hi Chris,

I hope you don't mind me responding though you would like to stop participating. This message is meant for other readers in case they are interested.

> 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.

The user story I put above had nothing to do with change. I was telling how manually performing integration tests between A and B is tedious for us (since it involves some form or the other of manual recording of input/outputs to the module B and adapting unit tests of B) while contracts are much better (for us) since they incur little overhead (write them once for B, anybody runs them automatically).

I did not want to highlight the change in my user story, but the ease of integration tests with contracts. If it were not for contracts, we would have never performed them.

Cheers,
Marko



On Mon, 8 Oct 2018 at 16:22, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano <steve@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@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@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/