[Python-ideas] Pre-conditions and post-conditions

[Paul Moore]

On Wed, 29 Aug 2018 at 23:08, Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
>
> Hi,
> I think we got entangled in a discussion about whether design-by-contract is useful or not. IMO, the personal experience ("I never used/needed this feature") is quite an inappropriate rule whether something needs to be introduced into the language or not.

It's not a key factor, but it is indicative, in the sense that if
no-one has ever needed the feature *in Python*, then it's possibly not
a good fit for how the language is used in real life. That doesn't
exclude the possibility of a new feature offering a new and not
previously considered technique, but if that's the assertion, then
it's up to the individual proposing the new feature to persuade the
community that there's a real and significant benefit.

> Is there any logical or empirical objection that the design-by-contract is not useful and hence does not merit to be introduced into the core language? There is little point in writing a PEP and fleshing out the details if the community will reject it on grounds that design-by-contract by itself is meaningless. So I'd suggest we clarify this first before we move on.

"It could be useful" is nowhere near a strong enough reason for
changing the language. Even "it is demonstrably useful in other
languages" would have a hard time. What you need to demonstrate is
that it would be useful *in Python code*. A good way of doing that is
by reviewing a significant body of real-life Python code (the standard
library is a common choice, but a big project like Django or
SQLAlchemy would also be reasonable) and demonstrating how the code
could be *improved* by using the proposed new feature. Here, the key
is that the change has to be an improvement - readability is one
(somewhat difficult to assess objectively) criterion, as is ease of
identifying bugs, or efficiency (less need to repeat complex
expressions, for example).

Conversely, any proposed new feature needs to address how it impacts
people who *don't* want to use it. That can be as simple as backward
compatibility issues such as adding new keywords (people using that
keyword as a variable name will have to change their code) but can
also address any general runtime impact in the interpreter
(bookkeeping and management of new data structures for example, or
changes to class implementation details). and how people who don't use
the new feature will be impacted if they encounter the feature in code
written by others, or in code reviews.

Also, there's the question of teachability. A proposed new feature
must address how it will be explained to new and existing Python
users. And given the confusion we're seeing in this thread ("aren't
these just runtime assertions?") that's something that contracts will
definitely have to address. I'm not saying that the proposal needs to
offer a full tutorial on design by contract, but at a minimum, it'll
have to cover why contracts aren't just runtime assertions, and how
the differences can be made clear in the documentation and by
trainers.

I hope that helps explain what you'll need to do if you want to take
this proposal forward, and why you're getting pushback in areas that
maybe seem incidental to you. Personally, I'm interested in the
feature, but I'm not sure I'm interested enough to want it in Python.
My main questions are

1. How exactly do these differ from simple assertions? I don't
understand the hints about "relaxing" and "strengthening" contracts in
subclasses, in particular I've no idea how I'd express that in actual
syntax.
2. Are we talking here about adding checks that would run in
production code? Wouldn't that slow code down? How do I deal with the
conflict between wanting tighter checks but not wanting to pay the
cost at runtime of checking things that should never go wrong
(contracts, as I understand it, are for protecting against code bugs,
that's why there's no facility for trapping them and producing "user
friendly" error messages)? I use assertions very sparingly in
production code for precisely that reason - why would I be more
willing to use contracts?

Paul