Typing of requests.HTTPError possibly too strict

[moltob]

Recent contributions #8989 and #10740 improved the typing of requests.HTTPError, so now we have:

typeshed/stubs/requests/requests/exceptions.pyi

Lines 13 to 16 in 5b8193b

	class HTTPError(RequestException):
	request: Request
	response: Response
	def __init__(self, *args: object, request: Request, response: Response) -> None: ...

This is causing issues in our code as it appears to be incompatible to the way requests itself is using the type:

Now the request argument is mandatory. However, requests itself does not do it this way, e.g. see the implementation of Response.raise_for_status:

Secondly, the type is now restricted to be Request. In particular this prevents assigning a PreparedRequest (which is not derived from Request). However, this is exactly what requests is doing in RequestException.__init__, in addition to explicitly allowing not to pass a request argument:

Please reconsider the strict typing.

@JelleZijlstra @srittau

[akx]

It looks like the type of request in the exception should be Request | PreparedRequest, since response.request is typed to be a PreparedRequest; trying to manually do HTTPError(response=resp, request=resp.request) now raises

Argument "request" to "HTTPError" has incompatible type "PreparedRequest"; expected "Request"

[srittau]

Thanks to @akx's PR, the request type is now relaxed. But per the example given I think the assumptions in #8989 and #10740 are wrong and we need to allow None values (and defaults) again for request and response.

[hsheth2]

I opened #10776 to fix this - @srittau let me know what you think.

[srittau]

types-requests 2.31.0.6 should fix the remaining issues when it gets released within the next few hours. Please comment here if there are still issues remaining, so we can reopen the issue. Thanks again to @akx and @hsheth2 for the fixes!

[djowett]

I still get an error like this in 2.31.0.6, is that intended?

 error: Missing named argument "response" for "HTTPError"  [call-arg]

the argument is indeed missing, but isn't that valid?

[srittau]

#10776 made only the request optional. If the response should also be optional, we'd need a PR to be able to judge the impact.

[srittau]

Some more discussion about HTTPError.response in #10875.

[AlexWaygood]

I still get an error like this in 2.31.0.6, is that intended?

 error: Missing named argument "response" for "HTTPError"  [call-arg]

the argument is indeed missing, but isn't that valid?

This should be fixed in the latest version of types-requests, following #10875.