classification
Title: urllib2.Request constructor has no timeout parameter
Type: Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: facundobatista Nosy List: facundobatista, jjlee
Priority: normal Keywords:

Created on 2008-03-21 22:58 by jjlee, last changed 2008-03-22 02:28 by jjlee. This issue is now closed.

Messages (5)
msg64291 - (view) Author: John J Lee (jjlee) Date: 2008-03-21 22:58
r55792 added timeout support to urllib2.  A timeout parameter was added
to urllib2.OpenerDirector.open(), but there is no corresponding Request
constructor parameter.  timeout is unique in that respect.  Instead,
OpenerDirector.open() sets req.timeout on request instances.  The
parameter "timeout" should behave in the same way as existing parameter
"data".
msg64304 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2008-03-22 00:50
The argument timeout can not have the same semantics than data, see the
following cases:

- r = Request(url)
- urlopen(r, data="foo")
- # data is "foo"

- r = Request(url, data="foo")
- urlopen(r)
- # data is "foo"

- r = Request(url, data="foo")
- urlopen(r, data="bar")
- # data is "bar"

So, what would happen if you put timeout in Request:

- r = Request(url, timeout=3)
- urlopen(r, timeout=10)
- # here, the final timeout can be 10, no problem!

- r = Request(url, timeout=3)
- urlopen(r)
- # Oops!

In this last one, which the final timeout should be? None, as you passed
that to urlopen()? Or the original 3 from the Request?

With data you can do it, because None has no meaning, so only you
replace the Request value if actually you passed something in urlopen().
But for timeout, None *has* a meaning...
msg64307 - (view) Author: John J Lee (jjlee) Date: 2008-03-22 01:05
This should be solved by introducing a "not set" value other than None.
msg64308 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2008-03-22 01:11
As I wrote in the other bug that you opened (#2451), introducing this
will complicate the usage and semantics of what is already established
and working.
msg64311 - (view) Author: John J Lee (jjlee) Date: 2008-03-22 02:28
I don't buy the "API complication" argument.

I might accept an argument that the timeout isn't really anything to do
with the request, so I won't bother to continue with this bug report.
History
Date User Action Args
2008-03-22 02:28:24jjleesetmessages: + msg64311
2008-03-22 01:11:18facundobatistasetmessages: + msg64308
2008-03-22 01:05:17jjleesetmessages: + msg64307
2008-03-22 00:50:47facundobatistasetstatus: open -> closed
resolution: wont fix
messages: + msg64304
2008-03-21 23:45:55facundobatistasetassignee: facundobatista
2008-03-21 23:17:42benjamin.petersonsetnosy: + facundobatista
2008-03-21 22:58:08jjleecreate