On Wed, Oct 24, 2018 at 9:08 PM Marko Ristin-Kaufmann <marko.ris...@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 >> library? > > > 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 contracts libraries. > * 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) compelling. > * 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. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
