Message166705
It's very hard to tell what ought to be done here, since Lib/urllib/request.py throws URLErrors with a great variety of order and number of arguments, and it's not clear how URLError (in Lib/urllib/error.py) intends to handle them.
However, in this case, AbstractHTTPHandler.do_open is instantiating URLError with another exception instance, and that exception contains .errno and .strerror. URLError puts the entire error instance into ``reason``, where the information is hidden away as .reason.strno and .reason.strerror.
In the name of keeping this information available rather than hiding it, I'm attaching a patch that adds to URLError.__init__:
if hasattr(reason, "errno"):
self.errno = reason.errno
if hasattr(reason, "strerror"):
self.strerror = reason.strerror
Again, I'm not sure this is the most logical approach because I can't find a consistent pattern in the ways URLError is instantiated. |
|
Date |
User |
Action |
Args |
2012-07-29 02:52:56 | catherine | set | recipients:
+ catherine, georg.brandl, amaury.forgeotdarc, orsenthil, ezio.melotti, r.david.murray |
2012-07-29 02:52:56 | catherine | set | messageid: <1343530376.45.0.947264484604.issue6471@psf.upfronthosting.co.za> |
2012-07-29 02:52:55 | catherine | link | issue6471 messages |
2012-07-29 02:52:55 | catherine | create | |
|