Fix inconsistent exception type in response.json() method

[steveberdy]

Summary

Fixes the inconsistency of errors thrown in the response.json() method in models.py, while preserving backwards compatibility.

What we used to have

Depending on whether or not simplejson was installed in the user's library, and whether the user was running Python 3+ versus Python 2, a different exception would get thrown when there was an issue with decoding response text as JSON. If simplejson was installed, simplejson.JSONDecodeError would get thrown. If not, json.JSONDecodeError would get thrown for Python 3+ users, and ValueError for Python 2 users. Thus, depending on the scenario, users would find themselves having to catch either simplejson.JSONDecodeError, json.JSONDecodeError, or ValueError in the case of the response.json() method failing. This inconsistency is not ideal.

What we have now

There is now one error class in exceptions.py that will represent all errors that can be thrown or caught in the response.json() method: requests.JSONDecodeError. All simplejson functionality was replaced with json functionality, but the new error type aliases both json.JSONDecodeError and simplejson.JSONDecodeError. If simplejson is not installed, its JSONDecodError is replaced with a plain Exception when aliased. If the user is running Python 3+, json.JSONDecodeError is aliased, but if the user is running Python 2, that is replaced with ValueError when aliased, as the JSONDecodeError was not previously a part of the json library. Now, all five error types, json.JSONDecodeError, simplejson.JSONDecodeError, ValueError, and requests.JSONDecodeError and its parent class requests.RequestException, will be caught from the requests.JSONDecodeError that will be raised.

Fixes #5794
@sigmavirus24

[steveberdy]

@sigmavirus24 @nateprewitt I made the necessary edits to fix workflow failures. Any feedback on Python 2 compatibility before running the workflows again? Thanks.

[nateprewitt]

Hi @steveberdy, I'd recommend setting up a testing environment locally with our tox script and something like pyenv to manage Python versions. If you're having difficulty with that, you can test changes yourself on another branch using Github actions in your own repository. That will help expedite your testing cycle and avoid needing to ping this thread every time a change is made.

[steveberdy]

@nateprewitt Thank you for the advice. I ran the workflows, and all tests passed: https://github.com/steveberdy/requests/actions/runs/1023889042

[steveberdy]

Is this ready to merge?

[nateprewitt]

Thanks for the updates, @steveberdy. I added a couple of comments for discussion. I'm not convinced they're necessarily the right direction, but it does feel like the simplejson/json problems are potentially being spread more places than needed.

Let me know what you think, thanks!

[nateprewitt]

Cool, I think this looks like we’re ready now. Thanks for seeing this through, @steveberdy.

For merging, I’m not sure if we want to put this on a 2.27.x branch while we wait for the next release, or if we merge now knowing we won’t do another patch release for 2.26.x. Any thoughts @sigmavirus24?

[sigmavirus24]

Let's just commit to the next release being 2.27.0. Heck we can push that out whenever and if we can get the proxy stuff merged too (once it's in a good state) then I think we can cut 2.27 with just these two "features"

[nateprewitt]

Alright, sounds like a plan to me. Thanks again, @steveberdy.