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

[Steven D'Aprano]

On Mon, Oct 08, 2018 at 04:29:34PM +1100, Chris Angelico wrote:
> On Mon, Oct 8, 2018 at 4:26 PM Marko Ristin-Kaufmann
> <marko.ristin at gmail.com> wrote:
> >> Not true for good docstrings.  We very seldom change the essential
> >> meaning of public functions.
> >
> > In my team, we have a stale docstring once every two weeks or even more often.

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. "
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22


> If it weren't for doctests and contracts, I could imagine we would 
> have them even more often :)
> >
> 
> 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.

That's not to say that contracts can't be used for libraries at all, but 
they're not so useful for public interfaces that could be called by 
arbitrary third-parties. They are more useful for internal interfaces, 
where you don't break anyone's code but your own if you change the API.

Think about it this way: you probably wouldn't hesitate much to change 
the interface of a _private method or function, aside from discussing it 
with your dev team. Sure it will break some code, but you have tests to 
identify the breakage, and maybe refactoring tools to help. And of 
course the contracts themselves are de facto tests. Such changes are 
manageable. And since its a private function, nobody outside of your 
team need care.

Same with contracts. (At least in the ideal case.)


-- 
Steve