Author demian.brecht
Recipients berker.peksag, demian.brecht, flox, loewis, mcjeff, polymorphm
Date 2014-12-15.05:28:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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('', transport=Transport(connection_factory=updated_timeout))

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.
Date User Action Args
2014-12-15 05:28:48demian.brechtsetrecipients: + demian.brecht, loewis, flox, mcjeff, polymorphm, berker.peksag
2014-12-15 05:28:48demian.brechtsetmessageid: <>
2014-12-15 05:28:47demian.brechtlinkissue14134 messages
2014-12-15 05:28:47demian.brechtcreate