On Wed, Oct 24, 2018 at 11:23 AM, Marko Ristin-Kaufmann <marko.ris...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
