This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author catherine
Recipients amaury.forgeotdarc, catherine, ezio.melotti, georg.brandl, orsenthil, r.david.murray
Date 2012-07-29.02:52:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343530376.45.0.947264484604.issue6471@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-07-29 02:52:56catherinesetrecipients: + catherine, georg.brandl, amaury.forgeotdarc, orsenthil, ezio.melotti, r.david.murray
2012-07-29 02:52:56catherinesetmessageid: <1343530376.45.0.947264484604.issue6471@psf.upfronthosting.co.za>
2012-07-29 02:52:55catherinelinkissue6471 messages
2012-07-29 02:52:55catherinecreate