Chris Angelico wrote:
For example, matplotlib's plt.show() method guarantees that... a plot will be shown, and the user will have dismissed it, before it returns. Unless you're inside Jupyter/iPython, in which case it's different. Or if you're in certain other environments, in which case it's different again. How do you define the contract for something that is fundamentally interactive?
Indeed, this is what bothers me about DbC fanaticism. It seems to have been conceived by people thinking about very computer-sciency kinds of problems, e.g. you're implenenting a data structure which has certain important invariants that can be expressed mathematically, and code can be written that checks them reasonably efficiently. All very neat and self-contained. But a lot of real-world code isn't like that -- much of the time, the correctness of a piece of code can't be tested without reference to things outside that piece of code, or even outside of the program altogether. How would you write DbC contracts for a GUI, for example? Most of the postconditions consist of "an image looking something like this appears on the screen", where "this" is a very complicated function of the previous state of the system and the user's input. IMO, the reason DbC hasn't taken off is that it assumes an idealised model of what programming consists of that doesn't match reality well enough. -- Greg _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
