I have tried several times (a couple of decades ago) to introduce DBC in Python, using one of the many available libraries (for an overview: see https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ ) but, like you, wasn't convinced.
I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.
> I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.
Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair
That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.
Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.
Finally, somebody said it! I am always bemused when people say they turn off contracts in production code. They don't understand the difference between contracts (a program state guarantee) and testing for special/error cases (must be handled explicitly). The excuse usually given is runtime performance which can be mitigated by using a subset from pre/post-conditions/invariants.
Exactly. What I do is litter my code with contracts. I then profile to find the hot loop and minimize (not turn them off) there. For the 99% of the other code, the user won't notice any slowdown.
The value is just too high to turn them off in production. Do you want bug free code? This is the only way I know how to do it.
But they also give you 4 different evaluation semantics (ignore, observe, enforce, quick_enforce) to tweak as needed. You don't need to do full checking everywhere and always.
Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair
That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.