[Python-ideas] Why is design-by-contracts not widely adopted?

Robert Collins robertc at robertcollins.net
Wed Sep 26 19:22:14 EDT 2018

On Thu., 27 Sep. 2018, 11:00 Chris Angelico, <rosuav at gmail.com> wrote:

> On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
> <robertc at robertcollins.net> wrote:
> >
> > On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
> > <marko.ristin at gmail.com> wrote:
> > >
> > > P.S. My offer still stands: I would be very glad to annotate with
> contracts a set of functions you deem representative (e.g., from a standard
> library or from some widely used library). Then we can discuss how these
> contracts. It would be an inaccurate estimate of the benefits of DbC in
> Python, but it's at least better than no estimate. We can have as little as
> 10 functions for the start. Hopefully a couple of other people would join,
> so then we can even see what the variance of contracts would look like.
> >
> > i think requests would be a very interesting library to annotate. Just
> > had a confused developer wondering why calling an API with
> > session.post(...., data={...some object dict here}) didn't work
> > properly. (Solved by s/data/json), but perhaps illustrative of
> > something this might help with?
> Not sure what you mean by not working; my suspicion is that it DID
> work, but didn't do what you thought it did (it would form-encode).
> Contracts wouldn't help there, because it's fully legal and correct.

Giving post a data= results in form encoding, as you say.
Giving it a json= results in json encoding.

Works is a bit of a weasel word.

The python code did not crash. However it did not perform as desired,

And since that is pretty much the entire value proposition of DbC... it
seems like a good case to dissect.

(Unless session.post() differs from requests.post(), but I doubt that
> that'd be the case.)

It doesn't.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180927/62537d67/attachment.html>

More information about the Python-ideas mailing list