Demian Brecht added the comment:

I'm a -1 to adding the timeout parameter to the ServerProxy implementation for 
pretty much the same reasons Jeff mentioned, but mainly because of the 
ambiguity that is introduced between the timeout and transport parameters (who 
should win in the case that they're both used?). I'm also a -1, although a 
little less strongly, on adding the timeout parameter to the transport layer.

Instead, what I would /like/ to see is to have a connection_factory parameter 
added to Transport.__init__ that takes a host parameter (i.e. what's passed 
into HTTPConnection here: 
which would default to a local function or lambda that does exactly what it's 
doing now. There are a few benefits to doing this:

1. Adding a timeout is just slightly less trivial than the current proposal
2. Encapsulation of the HTTPConnection object isn't broken
3. By exposing the ability to override the lower level HTTPConnection, 
connection_factory can result in a client that not only allows for setting 
changes such as timeouts, but can also result in any connection object that 
adheres to the expected HTTPConnection interface.

For me, the 3rd point is the biggest selling feature. Not only can tweaks such 
as the timeout be made, but if other features are required such as customized 
logging, exponential back-off and such, they can easily be implemented in a 
child class of HTTPConnection. You could even write a (possibly) trivial 
adapter layer to interface with a 3rd party HTTP library if you so chose to. 
So, instantiating a ServerProxy object with an HTTPConnection with a custom 
timeout in its transport layer might look like this:

    def updated_timeout(host):
        return HTTPConnection(host, timeout=42)

    proxy = ServerProxy('', 

While the use cases that you've used as examples can tend to happen, I firmly 
believe that those should be solved by enhanced documentation and not by 
implementation changes.

nosy: +demian.brecht

Python tracker <>
Python-bugs-list mailing list

Reply via email to