[Python-Dev] Getting an optional parameter instead of creating a socket internally (was: Re: stdlib socket usage and " keepalive" )

[Guido van Rossum]

On Mon, Apr 12, 2010 at 4:19 PM, Jesus Cea <jcea at 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)