search

getsentry / responses

A utility for mocking out the Python Requests library.
Apache License 2.0
4.14k stars 354 forks source link

deprecate `content_type` argument #675

Open beliaev-maksim opened 1 year ago

beliaev-maksim commented 1 year ago

Should we consider deprecating the content_type argument? It appears redundant in conjunction with the headers argument. Common tools like cURL and libraries such as requests do not provide a specific way to set the data type; it is typically managed through headers. Therefore, I propose that we consider deprecating the content_type argument to streamline the function signature and simplify the codebase. Instead, we could encourage users to utilize the headers parameter for specifying the content type. This would enhance clarity and maintain consistency with prevailing practices.

@markstory thoughts?

ThiefMaster commented 11 months ago

Please don't. It's nice 'syntactic sugar' for what's probably most common header. It also makes moving from httpretty much more straightforward.

ptalbert commented 2 months ago

At least for the responses recorder having the separate content-type causes some difficulty.

The recorder does not set the 'content-type' parameter when it saves a real http payload as a Response. This means Response.init sets the 'content-type' attribute value to 'text/plain' in every case. The recorder actually strips out the content-type http header (among others) and when the Response is written to the out.yaml file the Response.content-type is all you get and that is of course always 'text/plain'.

So when you load the output file into the responses registry the mocked Response does not necessarily have the same content-type header value as the original and some libraries process responses differently depending on the content-type header value. As an example: https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/client.py#L832

I've mad a stab at sorting this out for the recorder in #728 but it definitely made me wonder why it was done this way in the first place. It seems like at least the Response init should set its 'content-type' attribute from the input headers if it is there and only fallback to setting it to 'text/plain' when no value is given. But there is surely some historical context I am missing.