Better compatibility with requests library

[aparamon]

Long story short

aiohttp.ClientSession() is mostly compatible with requests.Session() (albeit async def vs def, of course). It is very convenient, as existing requests code can be converted to aiohttp straightforwardly. However, there are some minor incompatibilities.

It is easy to improve compatibility with requests without sacrifices, and is proposed to do so.

Expected behaviour

1. In requests, multipart-encoded files are passed via files argument while aiohttp.ClientSession uses data for that:
   http://docs.python-requests.org/en/master/user/quickstart/#post-a-multipart-encoded-file
   https://docs.aiohttp.org/en/stable/client_quickstart.html#post-a-multipart-encoded-file
   It is proposed that aiohttp.ClientSession also additionally recognizes files argument, processing it as data if set (effectively a compatibility alias).

2. Requests response object has status_code, while aiohttp.ClientResponse uses status:
   http://docs.python-requests.org/en/master/api/#requests.Response.status_code
   https://docs.aiohttp.org/en/stable/client_reference.html#aiohttp.ClientResponse.status
   It is proposed that aiohttp.ClientResponse additionally provides status_code compatibility alias.

Your environment

requests 2.21.0, aiohttp 3.5.2

[aio-libs-bot]

GitMate.io thinks the contributor most likely able to help you is @asvetlov.

Possibly related issues are #1625 (uvloop compatibility), #242 (Request's storage), #875 (Improve Request.repr), #682 (modifying request object), and #2421 (Cleanup web.Request).

[kxepal]

I think that doesn't worth much since aiohttp and requests are very different libraries and there is no reason to lie about the opposite by API mimic.

By declaring or taking some actions to have API compatibility with the requests we get the thin path to bound ourself with this compatibility which we'll have to maintain and support. It's also not about names and aliases, but behaviour as well.

These two bits are not the only difference between aiohttp client and requests and aiohttp never declared as drop-in async requests replacement. So why should we be?

On other hand, some beginner tutorial about requests-to-aiohttp migration which shows differences between libraries could be useful.

[asvetlov]

I agree.
One layer deeper beyond the very basic usage requests and aiohttp have very different API.

[aparamon]

Hi gents,
Thank you for the comments!

I agree that greater compatibility with requests cannot and probably shouldn't be declared as a project goal. Still, status vs status_code is both so annoying and easy to fix :-)

[asvetlov]

We have status in both client and server API for 5+ years.
I think the ship has sailed a long time ago.
P.S.
Also, status_code is 5 chars longer.

[aparamon]

Also, status_code is 5 chars longer.

Good point, and in fact I do like status more. However the little difference proves even greater nuisance compared to 5 additional chars :-/

Just to make it clear once more: it is neither proposed to replace status property not in the API nor in the docs; only providing an additional alias status_code. It looks like a very simple and safe addition.

P,S: Why not propose changes into requests, you might ask? :-) Well, requests predates aiohttp, and admittedly the former did influence the latter; not vice versa.

[asvetlov]

Sorry, no.
Keeping two aliases for the same property always adds a mental barrier but really doesn't solve compatibility issue: there are too many points where aiohttp.ClientResponse is different from requests.Response.