Exceptions having references to urllib3 exceptions in "message" field

Hey,

tldr; is exceptions keeping references to urllib3 exceptions a design choice?

I ran an issue when trying to automatically serialise TimeoutError.message. It appears it contains a reference to urllib3 exceptions:

>>> try:
...     requests.get('http://google.com', timeout=0.05)
... except Exception as e:
        pass
>>> e.message
ReadTimeoutError("HTTPConnectionPool(host='www.google.pl', port=80): Read timed out. (read timeout=0.05)",)
>>> e.message.__class__
<class 'requests.packages.urllib3.exceptions.ReadTimeoutError'>

Which is inline with I see in in the source

    elif isinstance(e, ReadTimeoutError):
          raise ReadTimeout(e, request=request)

but I wasn’t expecting this.

Python docs say:

The tuple of arguments given to the exception constructor. Some built-in exceptions (like IOError) expect a certain number of arguments and assign a special meaning to the elements of this tuple, while others are usually called only with a single string giving an error message.

Given the above I was expecting either:

1. message to be a string ( per typical use case )
2. message to be None and errno and strerror being set: ( because Request exceptions extend IOError and IOError having a specific constructor defined )

Was the current implementation a conscious decision? If not, what would be your preference, option (1) or (2) from the above? (2) seems more correct, (1) seems simpler.

Happy to try to PR.

Thanks!

[Lukasa]

As far as I can tell that should not be possible. If you’re using a custom transport adapter, though, they could be doing any number of things.

[nateprewitt]

Resolving as Python 2.7 being deprecated and we’re unlikely to be investing time fixing bugs that aren’t specific to Python 3.