[Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py. (original) (raw)

Facundo Batista facundo at taniquetil.com.ar
Wed Mar 21 18:49:12 CET 2007

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 createconnection() 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...

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().

Maybe we can settle all this by just putting timeout= and blocking= 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?

Thanks everybody for the patience...

Regards,

-- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

More information about the Python-Dev mailing list