[Python-ideas] Why is design-by-contracts not widely adopted?
steve at pearwood.info
Mon Oct 8 06:26:04 EDT 2018
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.)
More information about the Python-ideas