Jamie Lennox

That makes sense for libraries that might use other libraries that might add things after the fact. In that same vein, what about a multipart_form helper? This would be useful...

Yea, I'd be keen for that. Do you have a suggestion how that would look? There's cgi.parse_multipart which can do some of this, or somehow use cgi.FieldStorage (not sure how...

Fix proposed to branch: master Review: https://review.openstack.org/385740 Launchpad Details: [#LPC](https://bugs.launchpad.net/requests-mock/+bug/1632584/comments/5) OpenStack Infra - 2016-10-13 04:20:46 +0000

That was harder than expected, the handlers around multipart forms are really bad. I've put up what i think is reasonable at [1] based on top of the other form...

Hmm, that's interesting. I'm really interested in the description on the requests-cache documentation that requests-mock is different. In a way I guess we are, there is no such thing as...

There's actually a much more usable version of this in the requests-toolbelt: from requests_toolbelt.multipart import decoder md = decoder.MultipartDecoder.from_response(resp) That said, I realize this is something for the request object...

It's hidden because it's something that exposes a public interface but that a user should never have to instantiate directly. It was easier to make that private rather than commit...

Ah, i didn't look there. I wasn't thinking about requests doing this sort of decoding so i was searching for python decoders. So i completely agree that it's a nicer...

I don't particularly know a "lighter" way, short of just copying that code out of the toolbelt. I'm also not certain how you'd want to expose this frankly. I would...

Note also that #94 is an issue to actually provide type hints for requests-mock if you have some ideas how that should work i'll happily work with you on that....