requests in the stdlib?
Afternoon (or whatever else), gentlemen and gentle ladies! I guess I am not the first one who experienced a profound life-changing epiphany of meeting with the requests package. Yesterday after fighting for hours with urllib2 (and GitHub API) and failing, I have succeeded with requests in five minutes. Despite how much I dislike using libraries outside of the stdlib (yes, unittest is the way to go, please, no nosetests and py.test for me), I am now persuaded that requests API is the best thing since ... I don't know, API of feedparser (RIP, Aaron Swartz)? So, I guess, somebody had to already suggest pulling requests into stdlib. Could somebody here point me to the resulting discussion, please? Thank you, Matěj Cepl
On Mon, Nov 4, 2013 at 6:51 AM, Matěj Cepl <mcepl@redhat.com> wrote:
Yesterday after fighting for hours with urllib2 (and GitHub API) and failing, I have succeeded with requests in five minutes.
That was the bug, which can be fixed. Thanks for raising the bug
I think, the plan is to our http handling library enhanced with the request's style API. It is discussed at python-dev last year and at pycon. But it still will need to bring in fixes which requests has been doing for handing latest issues. -- Senthil
On 04/11/13 16:14, Senthil Kumaran wrote:
Is there some bug or thread I could follow? Thank you very much for the reply, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC в чужой монастырь со своим уставом не ходят. -- Russian proverb (this time actually checked by a native Russian)
On Mon, Nov 4, 2013 at 11:14 AM, Matěj Cepl <mcepl@redhat.com> wrote:
Nope as the bulk of the discussion happened at the language summit at PyCon 2013, so all in-person discussion. Basically that discussion said a requests-like API (or even requests if the right things happened) could go in the stdlib, but only if they support asyncio/tulip as a first-class way of using the library.
On Nov 04, 2013, at 03:51 PM, Matěj Cepl wrote:
requests is nice, and I like the API as well. I wouldn't be opposed to pulling it into the 3.4 stdlib if upstream were amenable. However, the specific implementation would have to stop vendoring various packages such as chardet and urllib3, and it would have to make it easy to use system provided certificates instead of bundling its own (there's been discussion on this issue for Python as well). We have to carry deltas in Debian to prevent this vendorization, and I think for Python stdlib they would be unacceptable. That probably means at least also pulling in urllib3 and chardet. -Barry
On 5 Nov 2013 06:15, "Barry Warsaw" <barry@python.org> wrote:
for think
PEP 453 vendors the whole thing as part of pip :) (but that's just one of the many ways that PEP makes life interesting for Linux distros). Anyway, yes, the requests *API* does likely represent the future standard HTTP(S) interface for Python, but more likely through an alternative asyncio compatible implementation rather than the current synchronous-only implementation. For now "pip install requests" (or the platform specific equivalent) is the way to go. Reference: http://python-notes.curiousefficiency.org/en/latest/conferences/pyconus2013/... Cheers, Nick.
On Mon, Nov 4, 2013 at 6:51 AM, Matěj Cepl <mcepl@redhat.com> wrote:
Yesterday after fighting for hours with urllib2 (and GitHub API) and failing, I have succeeded with requests in five minutes.
That was the bug, which can be fixed. Thanks for raising the bug
I think, the plan is to our http handling library enhanced with the request's style API. It is discussed at python-dev last year and at pycon. But it still will need to bring in fixes which requests has been doing for handing latest issues. -- Senthil
On 04/11/13 16:14, Senthil Kumaran wrote:
Is there some bug or thread I could follow? Thank you very much for the reply, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC в чужой монастырь со своим уставом не ходят. -- Russian proverb (this time actually checked by a native Russian)
On Mon, Nov 4, 2013 at 11:14 AM, Matěj Cepl <mcepl@redhat.com> wrote:
Nope as the bulk of the discussion happened at the language summit at PyCon 2013, so all in-person discussion. Basically that discussion said a requests-like API (or even requests if the right things happened) could go in the stdlib, but only if they support asyncio/tulip as a first-class way of using the library.
On Nov 04, 2013, at 03:51 PM, Matěj Cepl wrote:
requests is nice, and I like the API as well. I wouldn't be opposed to pulling it into the 3.4 stdlib if upstream were amenable. However, the specific implementation would have to stop vendoring various packages such as chardet and urllib3, and it would have to make it easy to use system provided certificates instead of bundling its own (there's been discussion on this issue for Python as well). We have to carry deltas in Debian to prevent this vendorization, and I think for Python stdlib they would be unacceptable. That probably means at least also pulling in urllib3 and chardet. -Barry
On 5 Nov 2013 06:15, "Barry Warsaw" <barry@python.org> wrote:
for think
PEP 453 vendors the whole thing as part of pip :) (but that's just one of the many ways that PEP makes life interesting for Linux distros). Anyway, yes, the requests *API* does likely represent the future standard HTTP(S) interface for Python, but more likely through an alternative asyncio compatible implementation rather than the current synchronous-only implementation. For now "pip install requests" (or the platform specific equivalent) is the way to go. Reference: http://python-notes.curiousefficiency.org/en/latest/conferences/pyconus2013/... Cheers, Nick.
participants (6)
-
Barry Warsaw -
Brett Cannon -
Ian Cordasco -
Matěj Cepl -
Nick Coghlan -
Senthil Kumaran