[...] If we are seriously considering DBC for Python, [...]
As I think I wrote in the previous thread about DBC in Python, there are already several DBC libraries on PyPI and we should precisely evaluate both their design and impact (e.g. usage).
The Wikipedia page for DBC lists a few others: "Python, using packages like deal, icontract, PyContracts, Decontractors, dpcontracts, zope.interface, PyDBC or Contracts for Python. A permanent change to Python to support design by contracts was proposed in PEP-316, but deferred."
here's is my initial
proposal for function and method contracts. I don't have a proposal for
class invariants as yet.
Deal (and similar, older, libraries) addresses similar needs, within the context of the existing Python syntax.
So yes, syntax can be improved. But :
1) Do people (at least a significant part) want DBC in their Python code. Is DBC still a popular idea in the software industry ?
(My 2 cts: I don't believe so).
2) Is one of the existing approach (i.e. through a library) enough for these persons, or do we really need to change the language ?
(I don't know, we need people who actually do DBC with existing libraries to tell us).
3) I think there is more to DBC that simply checking preconditions and postconditions and invariants at runtime, just as typechecking Python is a bit more work than sprinkling your code with "assert isinstance(something, SomeClass)".
Just as for type systems, DBC becomes really useful when you have a theorem prover that can prove (or refute) the consistency of your DBC constraints. This is the hard part (IMHO syntax is just the cherry on the cake).
Cheers,
S.