Hacker News new | past | comments | ask | show | jobs | submit login
Requests v2.0 Python module released (python-requests.org)
212 points by TheSwordsman on Sept 24, 2013 | hide | past | web | favorite | 37 comments

Congrats, Kenneth!

Requests is one of the best Python modules ever written, and I use it (literally) every day. Good stuff, man!


Cool! Requests has got to be my favorite Python library. There are so many times I have replaced ~80 lines of urllib2 ugliness with 2-5 lines of requests. Simple, Pythonic, pretty...

Same here, cuts having to write so much fugly code. Almost wish it was inclusive with Python itself since I primarily use the language for web dev.

I don't, this would require fundamental changes to the module (such as how it handles verifying SSL certificates) and it would cause API improvements to stagnate.

It's painless to install, so I prefer it as a module I can just add to all of my routines.

I feel like stdlib is where cool Python modules go to die...

I've been thinking about your last line. The rest of this comment is musings.

I think argparse is a cool module, and definitely better than optparse or getopt for the types of things I do. Both optparse and argparse were external packages before becoming part of Python. Optparse is dead, but I don't think that argparse is dead.

Some modules have a longer cycle time than Python. For examples, the decimal module (based on the 'General Decimal Arithmetic' standard) and sqlite module (based on SQLite).

I think these modules are cool. I don't think either of them are dead. (But on the other hand, the *bdb modules and the underlying implementations are dead.)

Some modules spun off, developed for a while on their own, and merged back into Python. Two examples were 'turtle2' and 'unittest2'. I enjoyed using unittest2, and am glad that it's part of Python 2.7 and newer. I never used turtle, but it was used in some computer classes. The turtle2 author pointed out that some computers are so locked down that the teachers can't change anything, which is why a 'turtle' in the base install can be useful.

Elementtree was and is a standalone package. I use it for nearly all of my XML parsing needs. It has a C extension as an accelerator, which isn't always painless to install, especially if I want a pure-Python distribution.

But on the other hand, minidom and the other XML-SIG package are dead. Then again, I didn't think they were cool. ;)

I looked at what modules were added in 3.2 and 3.3: lzma, faulthandler, ipaddress, argparse, concurrent.futures, unittest.mock, .. and that's about it.

(Interestingly, PEP 3156 would likely replace concurrent.futures.)

So I think others agree that only the most stable of APIs should go into Python core. But I don't think that all cool Python modules which get into the core die.

I guess I haven't considered restrictions on the machines where the modules are required. So there's definitely a reason for things making their way in to stdlib in those situations. (I wish the virtualenv stuff was packaged as part of core Python, to be honest...but that's a discussion for another time.)

My concern is the frustration (which may not be the right term) of having to continually bring things out of core, implement improvements, and then feed them back in to core. All the while being concerned with impact your changes may have on the entire ecosystem.

All-in-all, maybe it's just moot. This could probably just be chalked up to the ebb-and-flow of software development as a whole.

I looks like your complaint might be resolved soon. It seems that 'venv' is in Python 3.4 alpha http://docs.python.org/3.4/library/venv.html .

Yeah. It's going to be taken care of eventually. I guess I should really get more hell-bent on converting my things to Python 3.

I'm hanging on to 2.7 for dear life. I openly acknowledge I'm a bad person for it. :(

> I think argparse is a cool module, and definitely better than optparse or getopt for the types of things I do.

Have you tried docopt? https://github.com/docopt/docopt

No. I looked at it once though.

I might try it in the future, but I don't think useful to change my current system. I have internal type strings which look like this "RDKit minPath=3 maxPath=7" and command-line options like "--minPath=3 --maxPath=7".

I ended up making a registry of options which is used to validate the type strings and is used to populate argparse.

I also use custom decoders, like a decoder to enforce that a given value is >=32 and a power of two. A quick glimpse at the docs doesn't show a way to support that ability, so it would need to be rewritten to occur after arg parsing has finished rather than during.

I don't doubt that I could use docopt instead, but the amount of work to migrate doesn't seem worthwhile.

Even Guido van Rossum said "A package in the standard library has one foot in the grave".

Modules that get updated with things people need are cool. Stdlib modules can only be updated once per Python version, with great effort and extreme care not to break anything anywhere. So stdlib modules aren't cool.

What I don't understand is how this doesn't show up on top of Google's search results when you type "python rest client".

I bet TONS of time is wasted because it is harder to find this module than it should be.

Maybe we should learn Kenneth some SEO-fu. :p

requests is an HTTP library. REST is an architectural style.

Requests is a HTTP verb oriented HTTP client, REST is a HTTP verb oriented architecture. They are very compatible.

if so, OOP is purely functional programming oriented over a monoid in the category of endofunctors.


probably because the word 'rest' doesn't appear on http://docs.python-requests.org/ ?

Something like hammock (https://pypi.python.org/pypi/hammock/) would probably be more appropriate there.

This is probably the single thing I miss the most when not using Python. It's a really great example of writing a library that lets the user get right to the semantics they want while simplifying a bunch of mostly unimportant details.

There's a great improvement for the corporate environments too. Finally the https-over-http/connect is supported.

This has prevented me from using the official Jira python module. I literally just launched something hacky using urllib2 yesterday because of this... :(

What? Awesome! Been waiting for this for a looong time!

Good work. I'm not in Python anymore, but every other language I'm in, I wish I had Requests.

Do modules like this ever make it into the standard library?

I find it better that they stay out of the stdlib. Having to upgrade all of python just to get a new feature like CONNECT support would be unfortunate.

It also adds enormous friction to making changes/releasing updates in the first place.

the other side of this coin is that I've had things break between releases

and many/most people will have urllib{,2,3} inflicted on them by default not knowing otherwise

Cool! I did the `Session.prepare_request` change [1] and found the project maintainers extremely helpful and patient in discussing the best way to go about it as I stumbled around. It's a good codebase and an awesome library.

[1] https://github.com/kennethreitz/requests/pull/1507

Once again, thanks so much for that. Genuinely great work and we're so glad to have it.

Does this finally include SNI support?

The underlying issue is with Python 2.x (which is feature frozen and won't get SNI support) but apparently Requests can support SNI if you install PyOpenSSL, ndg-httpsclien and pyasn1

ref: https://twitter.com/mitsuhiko/status/363564610492063744

Have they added support for SOCKS proxies yet?

I'm currently using `import requesocks as requests`.

I find it much easier to route socks requests via Polipo (http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/)

Just run `polipo socksParentProxy=<host>:<port>` and then use it as a regular http proxy with requests (default port is 8123).

Which is good enough for singlular usage, it's crazy use it on servers.

It's being worked on.

I first used requests to earlier this year to handle some obscure calls to the twitter API, and was absolutely astonished by how much work it saved me. Really amazing work.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact