[Python-ideas] Contracts in python -- a report & next steps

[Nathaniel Smith]

On Wed, Oct 24, 2018 at 11:23 AM, Marko Ristin-Kaufmann
<marko.ristin at gmail.com> wrote:
> I imagine that you conceive contracts purely as an approach to a testing to
> be applied to a single project. I'm not talking about that. I'm talking
> about two packages on pypi, both specifying contracts, each developed by a
> separate team from different organizations. Let's call these packages
> package_a and package_b, respectively (and team A and B, analogously).
>
> Imagine now that the contracts are not standardized. For example, team A
> uses dpcontracts whereas team B uses icontract. Enter team C working on the
> package_c.

I appreciate your enthusiasm making Python better, and concern for the
ecosystem as a whole! But, right now, this particular problem is
mostly a theoretical issue, right? Currently 0% of the packages on
PyPI use any contracts library (within rounding error), so it'd be
very unlikely to have conflicts like this.

So in the future, a few different things could happen:

Maybe you fail to convince users that contracts are useful, so the
usage remains rare. In that case, the problem never happens.

Maybe icontracts is super successful, everyone adopts it, and it
becomes a de facto standard. Great! Now your problem is solved,
because everyone is using icontract.

Maybe two different contracts libraries become successful, and people
start hitting this problem for real. Something has to be done! But...
what? The Python core devs aren't going to know which library is
better, or where the pain points are, or how to best mitigate them.
The people best placed to figure that out are the developers of the
libraries, and their users. And even if we move one of them into the
stdlib, that won't magically force people to adopt it. The stdlib has
urllib, but most people use requests; the stdlib has ssl, but lots of
projects use pyopenssl...

In your position, I wouldn't be talking to the core devs; I'd be
writing blog posts to proselytize the advantages of contracts, working
with popular projects that are interested in adopting them, writing
case studies, going to meetups, submitting talks to pycons, that sort
of thing. If you want contracts to become a widely-used thing, you
have to convince people to use them. The core team doesn't have a
magic wand that can short-circuit that process.

> But if there existed multiple non-standard contract libraries, can we really
> expect that mypy deals with all of them? I couldn't possibly imagine that.

mypy currently ships with special support for both dataclasses and
attrs, which are basically two implementations of the same idea. If
there were multiple popular contract libraries, and there was some
benefit to mypy supporting popular contract libraries, then I assume
it would support all of them too. Why not?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org