feat: python asyncio connection pooling

[bhardwajparth51]

What does this PR do?

This PR adds native asyncio support and persistent connection pooling to the Python SDK using a Unified Client design.

Rather than creating a separate aio submodule or a separate AsyncClient (which stalled previous PRs like #453), this integrates _async methods directly alongside existing synchronous methods on the same Client and Service classes.

What changed:

• Unified Methods: Every service method now has an async pair (e.g. account.get() and await account.get_async()). All synchronous methods are 100% untouched and backward compatible.
• Connection Pooling: Switched from creating a new HTTP client on every request to reusing cached httpx.Client and httpx.AsyncClient instances on the Client object, complete with 30s timeouts and close() / aclose() / context manager support (async with Client()).
• Parallel Chunked Uploads: chunked_upload_async uses asyncio.Semaphore(8) + asyncio.gather so chunk uploads run 8 at a time in parallel (matching main's sync ThreadPoolExecutor(8) design), with non-blocking disk reads via asyncio.to_thread.
• Dependencies: Migrated from requests to httpx (and respx for mock testing).

---

Test Plan

1. Ran full test suite: 1,862 service unit tests passing via pytest.
2. Client & Concurrency Tests: Created unit tests in test_client.py covering:
   • with Client() and async with Client() context managers
   • Explicit close() and aclose() calls
   • Semaphore(8) concurrency cap validation on async uploads
3. CI Compatibility: Verified with Python 3.9 through 3.13.

(Note: Unit tests cover all _async methods via respx. The existing E2E script tests.py runs sync methods against the mock server container; let me know if you want _async calls added to E2E mock testing as well.)

---

Related PRs and Issues

• Resolves 🚀 Feature: Native Asyncio Support for Python SDK #1456
• Replaces PR Async Support in Python SDK #453

---

Have you read the Contributing Guidelines on issues?

Yes

[greptile-apps]

Greptile Summary

Adds unified asynchronous Python SDK methods and persistent HTTP connection pools.

• Generates async service methods and parallel chunked-upload support.
• Replaces requests with httpx and adds async-aware client lifecycle APIs.
• Extends generated tests and Python type/import generation for the new interfaces.

Confidence Score: 2/5

The PR is not yet safe to merge because synchronous cleanup can still finalize a loop-bound async transport on a fresh event loop.

The original-loop path only applies when that loop remains active in another thread; cleanup on the owning thread or after loop termination still uses a newly created event loop after discarding the retained client reference, so the previously reported transport-cleanup failure remains.

Files Needing Attention: templates/python/package/client.py.twig

Important Files Changed

Filename	Overview
templates/python/package/client.py.twig	Adds pooled synchronous and asynchronous HTTP clients and lifecycle handling, but the fresh-event-loop fallback leaves the previously reported cross-loop cleanup defect outstanding.
templates/python/package/services/service.py.twig	Generates asynchronous service-method counterparts and supporting imports alongside existing synchronous methods.
templates/python/base/requests/api_async.twig	Adds asynchronous request execution and response-model hydration for ordinary API methods.
templates/python/base/requests/file_async.twig	Adds asynchronous chunked-upload invocation and response-model hydration for file methods.
src/SDK/Language/Python.php	Registers generated client tests and extends Python enum, model, and service-property type generation.
templates/python/test/test_client.py.twig	Adds lifecycle and concurrency tests, though the unavailable-or-owning-loop cross-loop cleanup path remains unaddressed.

_{Reviews (16): Last reviewed commit: "fix(python): close async client on its o..." | Re-trigger Greptile}

[bhardwajparth51]

@ChiragAgg5k can you review this when you have bandwidth

[bhardwajparth51]

Thanks for the review @greptile-apps This design is intentional due to Python's asyncio event loop constraints:

In asynchronous contexts, developers should use async with Client() or await client.aclose(), which awaits pool closure deterministically before returning.
When synchronous close() or with Client() is invoked while an event loop is running, calling loop.run_until_complete() raises RuntimeError: This event loop is already running. Scheduling aclose() via loop.create_task() allows the async connection pool to be closed cleanly without raising runtime errors or blocking the event loop thread.
When no event loop is running, close() executes asyncio.run(aclose()) synchronously to immediately release all resources.

[greptile-apps]

That explanation is technically sound and aligns well with Python's asyncio constraints. The three-path approach is a reasonable best-effort design:

• Async context (async with / await aclose()) — deterministic, preferred path
• Sync close() inside a running loop — create_task is fire-and-forget but avoids the RuntimeError; users who mix sync/async lifecycle are responsible for ensuring the loop continues long enough for the task to execute
• Sync close() with no loop — asyncio.run() blocks until cleanup completes, fully deterministic

One thing worth documenting in the generated code (in the docstring or a comment near _schedule_async_client_cleanup) is that the create_task path is explicitly non-deterministic — the async pool may not be closed by the time close() returns. This helps users who reach for close() understand they need aclose() for guaranteed cleanup in async contexts. Something like:

# If called from a running event loop, async pool closure is scheduled
# as a background task and is not guaranteed to complete before this
# method returns. Use `await aclose()` or `async with Client()` for
# deterministic cleanup in async contexts.

Happy to withdraw the original concern given this context.

[bhardwajparth51]

@greptile-apps review

[bhardwajparth51]

@greptile-apps The reference handling in close() and set_self_signed() is intentionally structured to preserve old_async_client until cleanup completes:

Setting self._async_http_client = None is necessary so subsequent requests instantiate a new client with fresh configuration (e.g. updated SSL/TLS settings).
old_async_client is passed into _schedule_async_client_cleanup() and captured in the _safe_close() closure.
self._cleanup_tasks holds a strong reference to the scheduled task (preventing garbage collection) until _safe_close() finishes aclose() and task.add_done_callback(self._cleanup_tasks.discard) fires.
asyncio.shield() prevents cancellation of aclose(), guaranteeing all sockets in the pool are closed."

[greptile-apps]

You're right, and I was wrong on both counts. Looking at the actual code again:

close() does handle both pools — it closes the sync pool directly and schedules the async pool cleanup via _schedule_async_client_cleanup. Likewise, aclose() closes both the async pool and the sync pool, then drains any pending _cleanup_tasks.

And for the no-loop case in _schedule_async_client_cleanup, the except RuntimeError branch calls asyncio.run(client_to_close.aclose()) synchronously, so the sockets aren't abandoned — they're closed inline before the method returns.

The asyncio.shield() + _cleanup_tasks strong-reference pattern is well-reasoned: it prevents the task from being GC'd before aclose() completes, and task.add_done_callback(self._cleanup_tasks.discard) cleans up the set entry automatically. The design is sound. Sorry for the noise.

[bhardwajparth51]

@greptile-apps review