[Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
Guido van Rossum
guido at python.org
Wed Mar 21 18:58:48 CET 2007
On 3/21/07, Facundo Batista <facundo at taniquetil.com.ar> wrote:
> Guido van Rossum wrote:
>
> > (like httplib before the patch), I am personally in favor of going
> > back to defaulting timeout to None and skipping the settimeout() call
> > in _create_connection() if timeout is None. IMO the use case where
> > there is a global timeout set and one library wants to override it
> > with "no timeout" is pretty theoretical, and can just as well be
> > handled by passing sys.maxint as the timeout.
>
> In the new version of the patch (I updated it a few minutes ago), in
> _create_connection() I handle timeout being mandatory with **kwargs.
>
> And in HTTPConnection, I handle the posibility of calling it with
> timeout=None through a sentinel.
>
> It works, but my only issue is that it gets ugly in the help():
>
> >>> sentinel = object()
> >>> def f(a, b=sentinel):
> ... pass
> ...
> >>> help(f)
> ...
> f(a, b=<object object at 0xb7d64460>)
>
> I know I can use a class with __str__ instead of object, but what would
> one print in that case? In this case, "optional" does not means a value
> by default...
This is why I proposed to *get rid of* the distinction between
timeout=None and timeout not specified. Let an unspecified timeout
default to None, and if timeout is None, skip the settimeout() call.
> I don't have very strong feelings about how to use the function. I just
> need a timeout to HTTPConnection, to finally have it in
> urllib2.urlopen().
Yes, I remember well how it all started with a two-line patch to httplib.py :-)
> Maybe we can settle all this by just putting timeout=<int> and
> blocking=<bool> in create_connection, HTTPConnection, and urlopen().
> This way, the signature would be:
>
> _create_connection(address, timeout=None, blocking=None)
>
> and the behaviour:
>
> if timeout is None:
> if blocking is None:
> pass
> elif blocking:
> sock.setblocking(True)
> else:
> sock.setblocking(False)
> else:
> if blocking is None or blocking is False:
> sock.settimeout(timeout)
> else:
> raise TypeError("You can not block a socket and also time it out")
>
> This way we get off from the "timeout in None means something about
> blocking" trap.
>
> What do you think?
Overkill. The socket method settimeout() handles all with a single parameter.
> Thanks everybody for the patience...
Especially you, for volunteering to do this and then getting more
feedback than you bargained for!!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list