feat(python): enhance retry configuration in REST client

[timonrieger]

Description

Updated the retries parameter in the Python client Configuration so its type depends on the HTTP library:

• urllib3: Retry | int | None — passed through to the pool as connection pool kwargs (key_retries).
• asyncio: int | aiohttp_retry.RetryOptionsBase | None — int is turned into ExponentialRetry; otherwise the given RetryOptionsBase instance is used.

Type annotation: Optional[Union[int, Any]]. No isinstance checks in the urllib3 client as it does not require one; retries are passed through as-is.

Implements #17011

Other python generators, like httpx, tornado, etc. are out of scope as they either have no native retry mechanism or no maintained third party libraries

---

Checklist (unchanged from your template):

• Read the contribution guidelines
• Pull Request title clearly describes the work and description provides detail
• Run the following to build the project:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  Commit all changed files. CI verifies all generator outputs.
• File the PR against the correct branch
• If your PR solves a reported issue, reference it using GitHub's linking syntax
• If your PR targets a particular programming language, @mention the technical committee

---

Summary by cubic

Make the Python client's retry config transport-aware. Configuration.retries now accepts int or library-specific options for urllib3 and asyncio, enabling custom retry strategies and addressing #17011.

• New Features
  • urllib3: accepts int or urllib3 Retry; value passed through unchanged.
  • asyncio: accepts int or aiohttp_retry.RetryOptionsBase; int converts to ExponentialRetry and is reused.
  • Updated type hints/docs to Optional[Union[int, Any]] and clarified behavior in Configuration.

^{Written for commit 28850ba. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

[timonrieger]

as per PR template, mentioning the python team
@cbornet (2017/09) @tomplus (2018/10) @krjakbrjak (2023/02) @fa0311 (2023/10) @multani (2023/10)

[wing328]

thanks for the pr

please follow step 3 to update the samples

[timonrieger]

please follow step 3 to update the samples

done

[cubic-dev-ai]

1 issue found across 7 files (changes from recent commits).

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="samples/openapi3/client/petstore/python-httpx/petstore_api/configuration.py">

<violation number="1" location="samples/openapi3/client/petstore/python-httpx/petstore_api/configuration.py:170">
P3: Docstring for retries references aiohttp_retry types in a python-httpx client, which is misleading and inconsistent with this sample’s HTTP library.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P3: Docstring for retries references aiohttp_retry types in a python-httpx client, which is misleading and inconsistent with this sample’s HTTP library.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/openapi3/client/petstore/python-httpx/petstore_api/configuration.py, line 170:

<comment>Docstring for retries references aiohttp_retry types in a python-httpx client, which is misleading and inconsistent with this sample’s HTTP library.</comment>

<file context>
@@ -167,9 +167,7 @@ class Configuration:
-    :param retries: Retry config; type depends on library:
-        * urllib3: int | urllib3.util.retry.Retry
-        * asyncio: int | aiohttp_retry.RetryOptionsBase
+    :param retries: int | aiohttp_retry.RetryOptionsBase - Retry configuration.
     :param ca_cert_data: verify the peer using concatenated CA certificate data
       in PEM (str) or DER (bytes) format.
</file context>

[timonrieger]

since class based retries are only supported by the urllib3 and asyncio generators, but not httpx, tornado, etc. this might be misleading, as setting the class on retries has no effect on those. However before this PR the retries config option had no effect on those generators anyways