How do I get response headers?

How do I get response headers?

Ah yes, I'll change the type to an Union 👍

typing supports generics type
https://docs.python.org/3/library/typing.html#generics

The current api/*.py may need to be significantly revamped as it is not suited for giving type hints.

The current api/*.py may need to be significantly revamped as it is not suited for giving type hints.

Do you have any specific ideas in mind already?

Do you have any specific ideas in mind already?

No.

The goal of this PR is to have correct type annotations for the case that _return_http_data_only=True, right?

I think outside users are not supposed to set this flag, but rather use the plain client methods (not the _with_http_info methods) in order to get only the response object. So for users of the generated client, this PR makes the type annotations actually more complex without describing a valid use-case.

A nicer solution could be to remove the _return_http_data_only flag and always return ApiResponse.data in the plain client methods. That would always cause the construction of ApiResponse, but that has no logic, so it should be cheap. Type annotations and docstrings would be shorter and thus more user-friendly.

Thanks @fa0311 and @robertschweizer for the suggestions, I'll take a look at how to proceed.

From my understood, it would be better to:

• Remove _return_http_data_only completely
• Transform the _with_http_info methods to return a simpler answer, like only ApiResponse with the data inside
• Have the "normal" methods (not the _with_http_info ones) to return the high-level type

This could also simplify the ApiClient class: at the moment, the deserialization to high-level types is done in this class. If I implement the above, this means:

• ApiClient always returns ApiResponses
• The deserialization to high-level types moves closer to where the types are actually used

This may require larger changes in APiClient to achieve this and removing response_types_map from there. I'll take a look.

So, I made good progress on this, but this is also getting more complicated.

I created an issue to discuss about these changes, outside of this pull request: #16788

I will push my last changes in this pull request: it has most of what I discuss in #16788 except the new ApiRequest I mentioned: instead, most of the code is duplicated for now (hence, why I think we would need this).

There are still several mypy issues, but I think they are simpler to tackle after that:

• There are multiple ApiResponse classes defined, and they don't have the same interface.
• Some methods return Optional[Foo] instead of Foo as currently typed.

I haven't checked the rest yet.

I'll close this and check what we should actually do in #16788 instead.

I think the final result once #16788 is closed would be similar to this pull request, but it could be done in multiple smaller PRs, instead of this big one with many changes.