<div dir="ltr"><div>Hi Crhis,</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail-im">> In other words, you change the *public interface* of your functions<br>
> all the time? How do you not have massive breakage all the time?<br>
<br></span>
I can't comment about Marko's actual use-case, but *in general* <br>
contracts are aimed at application *internal* interfaces, not so much <br>
library *public* interfaces.</div></blockquote><div><br></div><div>Sorry, I might have misunderstood the question -- I was referring to modules used within the company, not outside. Of course, public libraries put on pypi don't change their interfaces weekly.</div><div><br></div><div>Just to clear the confusion, both Steve and I would claim that the contracts do count as part of the interface. <br></div><div><br></div><div>For everything internal, we make changes frequently (including the interface) and more often than not, the docstring is not updated when the implementation of the function is. Contracts help our team catch breaking changes more easily. When we change the behavior of the function, we use "Find usage" in Pycharm, fix manually what we can obviously see that was affected by the changed implementation, then statically check with mypy that the changed return type did not affect the callers, and contracts (of other functions!) catch some of the bugs during testing that we missed when we changed the implementation. End-to-end test with testing contracts turned off catch some more bugs on the real data, and then it goes into production where hopefully we see no errors.<br></div><div><br></div><div>Cheers,</div><div>Marko<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 8 Oct 2018 at 12:32, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br>
> > In other words, you change the *public interface* of your functions<br>
> > all the time? How do you not have massive breakage all the time?<br>
><br>
> I can't comment about Marko's actual use-case, but *in general*<br>
> contracts are aimed at application *internal* interfaces, not so much<br>
> library *public* interfaces.<br>
<br>
Yet we keep having use-cases shown to us involving one person with one<br>
module, and another person with another module, and the interaction<br>
between the two. Which way is it? Do the contracts change frequently<br>
or not? Are they public or not? How are we supposed to understand the<br>
point of contracts if the use-cases being shown all involve bad code<br>
and/or bad coding practices?<br>
<br>
Contracts, apparently, allow people to violate versioning expectations<br>
and feel good about it.<br>
<br>
(Am I really exaggerating all that much here?)<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>