HTTPretty 0.5.8 – mock HTTP requests in Python at the socket level

I really, really like this. I will definitely use it at work and for my own personal projects.<p>I will admit, though, that I'm not a fan of the rspec-like broken English. I hate to bikeshed here, because I really do love this idea, but these are just the opinions of myself, nobody particularly important. Feel free to disregard them :)<p>Some find the following to be more readable by the fact that it has more English words:<p><pre><code> expect(HTTPretty.last_request).to.have.property("querystring").being.equal({ ... </code></pre> It is in fact easy to read, but I find it very hard to write. The fact that the commands are so close to English throws me off more, because there are so many ways to construct a "sentence" that "sounds right" but is not equal to the desired command.<p><pre><code> expect(HTTPretty.last_request).to.have.property("querystring").being.equal({ expect(HTTPretty.last_request).to.have("querystring").being.equal({ expect(HTTPretty.last_request).to.have.property("querystring").equal({ expect(HTTPretty.last_request).to.have("querystring").equal({ </code></pre> I would personally prefer something like the following. Even though it isn't as friendly to non programmers and doesn't read like English at all, it's hard to get wrong.<p><pre><code> expect(HTTPretty.last_request).querystring.equals({ </code></pre> I obviously do not know enough about the project yet to know if there are so many potential properties (such as 'querystring') that the .property method became a structural necessity as opposed to syntactical sugar. If there aren't so many properties, I'd just hardcode them into methods/properties.<p>Once again, I really look forward to using this project, and it's perfectly okay to reject my opinions. The beauty of open source is that I can simply create a wrapper around what I dislike! :)

I wrote a wrapper around httpretty called httpetrified, which uses a python-requests serialization format. Instead of writing multiple lines inside the unit test describing the mocks, you can just record an actual response into a file and refer to it in a decorator.<p><a href="https://github.com/kanzure/python-requestions#decorator" rel="nofollow">https://github.com/kanzure/python-requestions#decorator</a>

This seems pretty neat (and you've thought of useful use cases like actually supporting streaming requests, yay!) but anything that involves globally monkey patching the entire socket library always makes me feel a bit like I should just go back and make the rest of my code suck a bit less.

Hmm... now I want this hooked up to a WSGI app in some way. Then you could, for example, have httpbin as a dependency and have it serve httpbin locally, thus giving you effective access to httpbin.org without needing an Internet connection. Or it could make handling some things for testing some web apps easier.

I'm currently building out a python client library for an HTTP rest API so this is invaluable to me. Thank you for the hard work!<p>Also, does anyone have an open-source project using this I could take a look at? Thanks!