

Requests, Python HTTP for Humans, reached v1.0 - jorde
http://kennethreitz.org/announcing-requests-v100.html

======
aidos
Congrats, Kenneth - Requests is a very nice library.

I've been using it a lot recently (though I've never had to go too deep into
it). I'm impressed with the simplification and removal of code in this
release. If only that was a goal for every project :)

~~~
pjscott
A nice thing about requests is that you almost never _have_ to go deep into
it. Out of the box, it almost always just does what you want. That's harder
than it sounds, as evidenced by the failure of the standard library's urllib
and urllib2 modules.

------
antoncohen
The choice of Apache 2.0 for the license is interesting. It makes the library
incompatible with GPLv2 software[1], but compatible with being integrated into
the Python standard library[2].

[1] <http://www.gnu.org/licenses/license-list.html#apache2>

[2]
[http://wiki.python.org/moin/PythonSoftwareFoundationLicenseF...](http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#line-75)

~~~
DArcMattr
I'd hardly characterize the ISC license as "esoteric". It's fairly compact,
yet plain in its language. Apache 2.0 takes a lawyer's help in trying to
understand.

------
mixmastamyk
Great work. It's a shame these nice libs weren't built a few years ago, they
might have had a chance to become the default in python3. Would be a killer
feature to push more people to it.

    
    
        "The entire codebase has been rearchitected"
    

I hope there are a few tests to check for regressions? ;)

~~~
SoftwareMaven
This is the part that concerns me. Generally, I think of code tightening in on
a release, which major swings early in the processes and minor tweaks later.
While I _all_ for everything that happened in this change, I wonder if a 0.2
(or even 0.9) would have been appropriate first. Version x.0 in open source
software implies "this is ready for production" (as opposed to commercial
software, where it seems to mean "let the beta test _really_ commence).

(I just noticed it is at 1.0.2 now. I think I'm going to have to give this a
couple weeks before I upgrade any of my projects.)

~~~
j-kidd
Look out for the change to the Request constructor that makes `url` no longer
the first parameter. Rather poor backward compatibility there.

~~~
sethish
It's a major revision number change, that's the only time to do such a major
api change.

~~~
j-kidd
While your point is valid, I didn't expect this to happen with requests. Just
two weeks ago, I was telling my colleague that requests is such a nice
library, we have nothing to worry about when installing a new version. Simply
grab the latest!

Then 1.0 happens. I have now moved requests to the "thoroughly test before
upgrade" pile.

~~~
kenneth_reitz
This is what major version numbers are for.

~~~
SoftwareMaven
It's an interesting challenge in the open source world to deal with. In closed
source software, having x.0 break things us understandable. We generally never
see all the effort between x.0 and (x+1).0.

In open source, it's harder because all of that is open, which means there is
a conflict between x.0 means "release" and x.0 means "development is just
beginning. It probably should mean the latter.

But then having a big "It's 1.0 and fabulous!" blog post is the wrong thing to
do. It probably should have been "It's 1.0; be careful!" I don't see how you
can have it both ways. Linus took care of that with odd/even versioning, but I
think you need a huge project for people to pay enough attention to understand
unless it became a _de facto_ standard (which it hasn't in over a decade, so
it's unlikely to).

(BTW, I am very grateful for the work you've put into this. Requests is truly
a model API. My comments are much more meta about versioning and open source
in general (using this project as an example) and should in no way be
construed as saying I think you are doing something wrong.)

------
funkiee
There's this interesting narrative that develops from time to time in Hacker
News. Maybe it's just observer bias, but I had never heard of requests for
Python until I read an article on HN about scraping, which in turn got me
interested in Python, and now a week later a major release of Requests happens
with a top story on HN.

------
graue
Is the blog post the only direct documentation of what needs to change to
upgrade to 1.0?

Details seem relatively scant. But maybe that's because response.json() is the
only feature I'm using that changed...

------
alexholehouse
This is great new - I recently integrated requests into my current project,
and it's made many things a lot easier!

------
nicolasp
Is the verbose mode still around? Not having any configuration is nice, but
what replaces this?

    
    
       session.config['verbose'] = sys.stderr
    

I couldn't find anything about it in the API docs.

~~~
kenneth_reitz
I replaced it with _real_ logging!

Need to show how to use it in the docs still.

------
isabre
Used Requests in one of my projects. Definitely one of the best modules out
there. Great news for all Python devs.

------
bob_hancock
Last week, I showed requests to a class of sysadmins to whom I was teaching
Python and they were blown away. Great work.

------
SiVal
This sounds great. I assume it's Python 3, right?

~~~
kenneth_reitz
2.6–3.3

~~~
TorKlingberg
If you can share some advice on Python 2/3 compatibility that would we very
interesting. Especially things related to Unicode and testing. I see you have
a single codebase for both versions. That is the same approach I took with my
(much smaller) library, but several people advised against it. I also see you
have very few "from __future__ import ..." Is that a conscious decision?

In any case, thank you! I will use Requests as an example to follow.

~~~
tshepang
Using a single codebase for both Python 2 and 3 seems the most fashionable
thing these days. It is, after all, the approach followed by Pyramid and
Django. I also think it makes maintenance easier. The __future__ import is a
consequence of it.

------
jkbr
Congrats, Kenneth!

Any hints on how to solve these incompatibilities between HTTPie and Requests
v1.0 appreciated: <https://github.com/jkbr/httpie/issues/113>.

------
domrdy
Very nice, Thank you! I'm curious, why did you remove the json property?

~~~
tbatterii
just a guess but if .json was implemented as a property and deserialization
fails, you would get an AttributeError instead of the error reporting that
there was a problem with deserialization. leaving it a method call would allow
for the real error to bubble up as normal.

~~~
kenneth_reitz
Bingo :)

~~~
tbatterii
i pretty much stopped using properties after I got bit by that. :)

------
michaelmior
Looks great! Unfortunately this broke one of our external dependencies which
was careless enough to specify any version greater than 0.14.

~~~
j-kidd
This is why we should maintain our own pypi repository. Your external
dependency did nothing wrong.

------
Radim
Good job I guess (I use `requests` all the time and didn't even notice any
issues, that's how neat it is). But the marketing-speak here makes my hair
bristle!

"Requests is SEXY AWESOME!" "No wait, it's crap, complex, hard-to-follow code.
But the NEW version is SEXY AWESOME!" (...at least until the next release, I
suppose)

~~~
kenneth_reitz
The developer interface was elegant, but the internal code left something to
be desired.

That is no longer the case.

~~~
RyanZAG
Leaves the following interesting question:

If the developer interface was elegant, and the library itself ran very well
without any errors, is anything actually gained by making the internal code
elegant?

What happens if the new version, while more elegant internally, has a new
complex bug in it (such as a race condition, that only triggers once every
billion requests)? Still worthwhile to fix up the inelegant code that was
working correctly?

(Disclaimer: I feel it's better to clean it up regardless, but I have a
feeling a study would show something different in terms of lost
productivity...)

~~~
kenneth_reitz
It does surface to the lower-level user interfaces, as shown in the blog
post's connection adapter example. For advanced users, these changes will mean
the world.

The new code is also _much_ easier to debug and pleasure to work with. Bugs
will be significantly easier to fix :)

------
cmancini
Congrats. Requests has been super useful to me. Awesome stuff.

------
fatbird
Congratulations Kenneth! Well earned, well deserved.

------
kros
Next step... Tablib v1.0? ;)

~~~
kenneth_reitz
Actually, yes :)

~~~
kros
Great! There is a problem with pip install tablib:

<http://dpaste.com/hold/847350/>

xlwt3 development stopped: <http://pypi.python.org/pypi/xlwt3/0.1.2>

Maybe xlwt3 could be replace by openpyxl?
<http://pypi.python.org/pypi/openpyxl/1.6.1>

~~~
kenneth_reitz
Going to do something similar. Remove all the formats. Pull them into separate
libraries.

------
leoplct
What's the equivalent for Ruby?

~~~
Goopplesoft
Restclient as well from <https://github.com/archiloque/rest-client>

------
jimmytucson
Can we all agree that it's a little weird to pause mid-article to fawn upon
one's own code?

I love Kenneth Reitz and admire his skill but "come on, man."

~~~
mattdeboard
No, we can't all agree that anything about that post was "weird". I didn't
even see any "fawning". Just someone who's enthusiastic about his code. It's
ok to love something you made and let people you think it's great. "Fawning"
doesn't even mean what you think it means.

~~~
kenneth_reitz
Yeah, it's not like I want to tattoo the source code all over my body or
anything.

~~~
dguaraglia
Haha, on the other hand, one of the typical interview questions is 'mention
something you built that you are proud of'. A developer's satisfaction with
his own craftsmanship is, to me, a must.

~~~
slurgfest
So you can't just produce good, solid output without congratulating yourself
in public? Interesting.

~~~
dguaraglia
No, what I meant is that if someone _is_ proud of their code and aren't afraid
to share it with the world you should know probably lighten the hell up and
let them be.

