On Mon, Apr 12, 2010 at 4:19 PM, Jesus Cea <jcea@jcea.es> wrote:
On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
Jesus Cea <jcea <at> jcea.es> writes:
PS: "socket.setdefaulttimeout()" is not enough, because it could shutdown a perfectly functional connection, just because it was idle for too long.
The socket timeout doesn't shutdown anything. It just puts a limit on how much time recv() and send() can block. Then it's up to you to detect whether the server is still alive (for example by pinging it through whatever means the application protocol gives you).
A regular standard library (let say, poplib) would abort, after getting the timeout exception.
4. Modify client libraries to accept a new optional socket-like object as an optional parameter. This would allow things like transparent compression or encryption, or to replace the socket connection by anything else (read/write to shared memory or database, for example).
This could be useful too.
I have been thinking about this for years. Do you actually think this could be formally proposed?.
What bugs me is that the socket creation is deep inside the stdlibs. You can not control it easily (I have overloaded socket.socket() in the past for controlling the number of concurrent connections to servers, for instance, or providing encryption), and it is difficult to test.
If these stdlib methods could accept an optional parameter instead of creating the socket internally, test is trivial, and you can reuse the lib to access the service via an arbitrary object (this weekend I just tunneled TCP/IP via DNS requests/answers, shame on you, airport wifi hotspots!).
Yeah, this sounds like a useful change. Would be very useful for testing too. -- --Guido van Rossum (python.org/~guido)