On Thu., 27 Sep. 2018, 11:00 Chris Angelico, <rosuav@gmail.com> wrote:
On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
<robertc@robertcollins.net> wrote:
>
> On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
> <marko.ristin@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