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