4 ms·

I really, really like this. I will definitely use it at work and for my own personal projects. I will admit, though, that I'm not a fan of the rspec-like broke

by RegEx 14y ago

I really, really like this. I will definitely use it at work and for my own personal projects. 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 :) Some find the following to be more readable by the fact that it has more English words: expect(HTTPretty.last_request).to.have.property("querystring").being.equal({ ... 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. 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({ 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. expect(HTTPretty.last_request).querystring.equals({ 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. 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! :)

derelk 14y ago
I agree. I really winced at that bizarre syntax. I find it strange to read and painfully unintuitive to write. It's not just "un-Pythonic"; it's unlike almost any other library. I would also imagine the strange structure and all those nested accessors makes debugging and developing for the library itself unnecessarily complicated, thereby impeding contributions to the project itself.
kisielk 14y ago
You don't have to do that. It's just the test framework they are using alongside HTTPretty in their examples. You can just as easily use the traditional unittest.TestCase methods: self.assertEqual(HTTPretty.last_request.querystring, "whatever") self.assertEqual(HTTPretty.last_request.method, HTTPretty.GET) That is what I do in my tests.
- RegEx 14y ago
  Ah, I see, thanks!

by RegEx 14y ago

derelk 14y ago

I agree. I really winced at that bizarre syntax. I find it strange to read and painfully unintuitive to write. It's not just "un-Pythonic"; it's unlike almost any other library. I would also imagine the strange structure and all those nested accessors makes debugging and developing for the library itself unnecessarily complicated, thereby impeding contributions to the project itself.

kisielk 14y ago

You don't have to do that. It's just the test framework they are using alongside HTTPretty in their examples. You can just as easily use the traditional unittest.TestCase methods: self.assertEqual(HTTPretty.last_request.querystring, "whatever") self.assertEqual(HTTPretty.last_request.method, HTTPretty.GET) That is what I do in my tests.

RegEx 14y ago
Ah, I see, thanks!