[Python-ideas] Contracts in python -- a report & next steps
rosuav at gmail.com
Wed Oct 24 06:24:24 EDT 2018
On Wed, Oct 24, 2018 at 9:08 PM Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
> Hi Chris,
>> For the sake of those of us who REALLY don't feel like diving back
>> into the extensive threads on this subject, can you please summarize
>> the benefits of having this in the stdlib rather than as a third-party
> Certainly. We need a standard approach to contracts as opposed to third-party libraries for the following technical reasons:
> * There is no dependency hell if two packages use different versions of the same contract library.
Wouldn't version differences happen just as much whether it's in the
stdlib or a third-party library? The contracts API has to be built to
cope with this, regardless. But having it in the stdlib would at least
mean that you don't have to worry about incompatible DIFFERENT
> * Two packages need to inherit each other's contracts (e.g., one package defines a class which inherits a base class from a different package and hence needs to inherit its contracts as well).
Ditto. So, small benefit. Enough to be of value, but not (on its own)
> * Third-party libraries for testing and static verification need a standard approach to contracts in order to be usable. Otherwise, the authors of these libraries (e.g. Hypothesis) need to support multiple contrat libraries (if they could ever bother to support multiple of them).
And ditto again. So I would disagree that these benefits are critical,
but they are definitely benefits.
>> Also - have you benchmarked the performance cost of adding contracts?
>> Particularly: if you're planning to contractify the stdlib, what is
>> the impact on startup performance?
The main question is: are you intending for the standard library to be
annotated with contracts?
If not, all your proposed benefits can be achieved at the level of a
single project, by just saying "we're going to use THIS contracts
library", unless I'm misunderstanding something here.
If so, you suddenly have to figure out how much longer it takes
*across all of Python's startup*. How much longer will it take to run
"hg help" with annotations set up? That's the kind of benchmark that's
going to make or break this proposal. Adding a notable delay to
command-line tools like that would seriously hurt.
More information about the Python-ideas