Author demian.brecht
Recipients demian.brecht, jimr, martin.panter, orsenthil, r.david.murray
Date 2015-03-02.17:19:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <AD2B0643-5E47-47B2-BAC0-24A1F0CBF8F8@gmail.com>
In-reply-to <1425309547.34.0.459677590953.issue23539@psf.upfronthosting.co.za>
Content
> Aside from that, however, I see request.('GET', '/') and request.('GET', '/', '') as clearly *different* from an API call standpoint, so I would in any case preserve the existing behavior.

I do understand the case that the the two examples look different from a caller’s standpoint. However as a user, I’d expect the library to do the Right Thing due to a deeper understanding of the theory behind the API that I’m using. Perhaps it would have made more sense to default body to empty string rather than None in which case there wouldn’t be a need for this distinction.

That said, I do understand the reasoning behind not breaking backwards compatibility and it’s not a problem until reported and am not looking to get into an API design argument (especially for something as low impact as what I was proposing). So @James, I stand corrected :)
History
Date User Action Args
2015-03-02 17:19:31demian.brechtsetrecipients: + demian.brecht, orsenthil, r.david.murray, martin.panter, jimr
2015-03-02 17:19:31demian.brechtlinkissue23539 messages
2015-03-02 17:19:31demian.brechtcreate