On 2011-03-25, at 10:22 , Simon Cross wrote: > On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> As an example of the last point, perhaps rather than modifying all the >> *clients* of the socket module, it may make more sense to have tools >> in the socket module itself to temporarily customise the socket >> creation process in the current thread. The advantage of such an >> approach is that it would then work for 3rd party libraries that >> create sockets, without requiring any further modification. > > -2. That wouldn't allow one to use normal sockets in one 3rd party > library and special sockets in another 3rd party library. > > Schiavo > Simon
Or even in "first-party" code (in the stdlib) to set different timeouts on different APIs (say, an xmlrpclib.ServerProxy and an IMAP4 client). For instance, currently as far as I can tell setting a socket timeout on an xmlrpclib.ServerProxy without setting a global timeout involves: * subclassing all of xmlrpclib.Serverproxy, xmlrpclib.Transport, httplib.HTTP and httplib.HTTPConnection * overloading __init__ on the ServerProxy subclass (and on Transport if the timeout is to be a parameter) * overloading make_connection on the Transport subclass (in order to use the HTTP subclass and propagate the timeout) * overloading _connection_class on the HTTP subclass * overloading connect on the HTTPConnection class This *could* be solved by wrapping a socket-related thread-local context manager around each call resulting in the creation of a socket, but these call sites may not even be under control. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
