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

[Robert Collins]

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,
either.

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.

Rob

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