[Python-Dev] Getting an optional parameter instead of creating a socket internally

[Nick Coghlan]

Jesus Cea wrote:
> On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
>> Jesus Cea <jcea <at> jcea.es> writes:
>>> 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?.

This strikes me as the best way forward (albeit far from easy to do):

1. Existing code which doesn't use the new arguments should be unaffected.

2. No changes to low level socket code, so no chance of unintended side
effects on library behaviour

3. Solves a broad class of problems (i.e. allows all sorts of tunnelling
and various socket options) rather than just this one problem.

4. Allows easier library testing with "mock" socket objects.

The problem actually reminds me of Spolsky's Law of Leaky Abstractions
essay. If the abstraction layer is going to leak anyway (and they always
do), it's best to give the developer access to all of the tools they
need to plug the hole.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------