On Thu, Sep 27, 2018 at 9:22 AM Robert Collins
On Thu., 27 Sep. 2018, 11:00 Chris Angelico,
wrote: On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
wrote: On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
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.
Okay, but what is the contract that's being violated when you use data= ? How would you define the contract that this would track? That's what I'm asking. ChrisA