[Python-Dev] Regarding socket timeouts in httplib
Consider the following code for retreieving a web page using httplib:
def get_url(hostname, port, url, timeout=5):
con = httplib.HTTPConnection(hostname, port, timeout)
con.request("GET", url)
res = con.getresponse()
data = res.read()
return res, data
As expected, this will raise a socket.error if the client is unable to
connect before the timeout has expired. However, once the connection
has been made, the timeout parameter no longer has any effect and
con.getresponse() will block forever if the server does not send any
data.
I think the reason for this is that the socket object created in
HTTPConnection.connect() has a default timeout of 0 (i.e. it is never
set explicitly):
def connect(self):
"""Connect to the host and port specified in __init__."""
self.sock = socket.create_connection((self.host,self.port),
self.timeout)
For now I have been able to work around this by manually setting the
timeout of the (private) socket object after calling con.request(),
like this:
...
con.request("GET", url)
con.sock.settimeout(timeout)
res = con.getresponse()
...
However, I don't think this is a very good solution as it relies on
knowledge about the inner workings of httplib (and I had to read the
library source code to come up with it).
>From the top of my head, I can come up with three (four) ways of
properly solving the issue:
1) Documenting the timeout behavior and describing the above hack in
the httplib documentation.
2) Modify HTTPConnection.connect() to set the timeout on the socket
object after it has been created (using the same timeout as given on
the HTTPConnection constructor).
3) Adding (optional) timeout parameters to
HTTPConnection.getresponse() and HTTPResponse.read() (and possibly
other functions with the same problem).
4) A combination of 2) and 3).
Any thoughts on this?
BTW: Once I figure out how, I wouldn't mind submitting a patch for
either 2), 3) or 4), but personally I don't like 1).
Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Curious datetime method
> I wonder why would anyone want to use datetime.today() instead of > datetime.now()? Because this method is also present in datetime.date. Thus, you can reference stuff like d.today().day without caring whether d is a date or a datetime object. Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Curious datetime method
On Tue, Jul 20, 2010 at 5:56 PM, Alexander Belopolsky wrote: > In the real world where we have to take backward compatibility into > account, I would like to make today() and now() to be the same: both > taking optional tz argument, both available as either date or datetime > methods and both covariant. the justification for having two methods > doing exactly the same will be just readability: date.today() and > datetime.now() are more readable than date.now() and datetime.today(). I agree. Unless, of course, someone has a good explanation/reason for why today() and now() are implemented differently (i.e. a use case where the difference is significant). Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Set the namespace free!
On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith wrote: > Yuck. Anyone who feels they need a variable named the same a reserved word > simply feels wrong and needs reeducation. [...] While I agree with you in principle, I have been finding it frustrating trying to calculate yield in my financial applications lately... ;) That being said, yield is pretty much the only (reserved) word I have had problems with finding (descriptive) alternative (variable) names for, so far. Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] i18n
On Sat, Aug 14, 2010 at 10:18 AM, Jeroen Ruigrok van der Werven wrote: > I doubt you will be able to localize much with regard to the interpreter. > The only thing that really comes to mind are the error and exception > messages, but you will never be able to localize the errors themselves. The > problem there is that if they seek help on international fora for Python, > other people might have no clue what the (error) message even means. I think one way to solve this might be to include the original (English) error message as well as the translation. I've noticed this is how error messages are handled in localized versions of Oracle, and although I'm personally annoyed by it, I can see how some people might find it useful. For example: >>> cause.error() Traceback (most recent call last): File "", line 1, in NameError: name 'cause' is not defined localized to Norwegian, could become: >>> cause.error() Tilbakesporing (nyeste kall sist): Fil "", linje 1, i NameError: navn 'cause' er ikke definert (name 'cause' is not defined) I think translating the actual error text would make sense, but I'm not so sure about localizing the traceback output itself... Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
