You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! 👋 Adding an HTTPXodus data point to this thread (one coordinated comment per project — no spam).
I'm running the HTTPXodus community effort to help major projects plan their path off the stalled httpx stable line onto httpx2, the actively maintained fork by Pydantic Services (Tom Christie involved). Five large projects have already migrated — Starlette (12.5k★), FastAPI (102k★), OpenAI Python SDK (31.5k★), Anthropic Python SDK (3.9k★), MCP Python SDK (24k+★) — and the pattern in every case is the same.
A few concrete things that might be useful for the next issue @harshil21 mentioned:
1. The actual surface in PTB is tiny. With the src/ refactor, only two production files import httpx:
File
What's there
src/telegram/request/_httpxrequest.py
The whole networking layer — builds httpx.AsyncClient/Timeout/Limits/AsyncHTTPTransport, catches httpx.TimeoutException (with isinstance(err, httpx.PoolTimeout)) and httpx.HTTPError
src/telegram/ext/_applicationbuilder.py
Only httpx.Proxy/httpx.URL as public type annotations on Builder.proxy() / Builder.get_updates_proxy()
2. requires-python = ">=3.10" is already a non-issue for httpx2. No python-version gymnastics needed.
3. Since PTB is a library, the recommended shape is Option A (dual import) so existing users on httpx<0.29 don't break:
pyproject.toml would gain httpx2>=2.12.0; python_version >= '3.10' alongside the existing httpx >=0.27,<0.29. The python_version marker is a no-op under your current requires-python but documents the floor.
4. Public-API caveat.httpx.Proxy and httpx.URL appear in Builder.proxy()'s annotation, so they're part of the public type surface. With Option A the resolved annotation will be httpx2.Proxy | httpx2.URL when httpx2 is installed. Duck-typing at runtime keeps user-passed httpx.Proxy instances working fine (httpx2 keeps the same class hierarchy), but type-checkers downstream will see a different module name. Worth a sentence in the changelog either way.
5. The same TLS caveat I included in the HTTPXodus issue template applies to PTB: httpx2 verifies against the OS trust store instead of certifi, so containerised and corporate-proxy users will see different behaviour. Flagging it here since PTB users span a wide range of deployment environments.
6. If the "different networking backends" angle is the actual plan (e.g. aiohttp or a custom transport), that's totally fair — Option A is opt-in and doesn't preclude it. I just want to make sure python-telegram-bot[http2] and [socks] continue to work under whichever path you pick.
7. Ready to open the PR. The HTTPXodus bot migration in mem0 (issue #7207) and the AutoGPT one (PR #14271) both follow the dual-import pattern and pass their full test suites. Happy to mirror that here — diff would be ~8 files, all 4 of the affected tests would import httpx2 to match the SUT, no test code logic changes.
If you'd rather wait for httpx 1.0 stable, totally understood — I'll close my side and stop pinging. Just wanted to make sure the option was visible alongside the other backends @harshil21 mentioned. 🙏
Activity
harshil21 commentedon Jun 9, 2026
Hello,
We are aware of httpx's situation, and are considering different networking backends. We'll have another issue covering this soon.
Kludex commentedon Aug 2, 2026
I've created this migration guide, in case it helps: https://httpx2.pydantic.dev/migration/
SiAgentBuild commentedon Sep 3, 2026
Hi! 👋 Adding an HTTPXodus data point to this thread (one coordinated comment per project — no spam).
I'm running the HTTPXodus community effort to help major projects plan their path off the stalled
httpxstable line ontohttpx2, the actively maintained fork by Pydantic Services (Tom Christie involved). Five large projects have already migrated — Starlette (12.5k★), FastAPI (102k★), OpenAI Python SDK (31.5k★), Anthropic Python SDK (3.9k★), MCP Python SDK (24k+★) — and the pattern in every case is the same.A few concrete things that might be useful for the next issue @harshil21 mentioned:
1. The actual surface in PTB is tiny. With the
src/refactor, only two production files importhttpx:src/telegram/request/_httpxrequest.pyhttpx.AsyncClient/Timeout/Limits/AsyncHTTPTransport, catcheshttpx.TimeoutException(withisinstance(err, httpx.PoolTimeout)) andhttpx.HTTPErrorsrc/telegram/ext/_applicationbuilder.pyhttpx.Proxy/httpx.URLas public type annotations onBuilder.proxy()/Builder.get_updates_proxy()2.
requires-python = ">=3.10"is already a non-issue for httpx2. No python-version gymnastics needed.3. Since PTB is a library, the recommended shape is Option A (dual import) so existing users on
httpx<0.29don't break:pyproject.tomlwould gainhttpx2>=2.12.0; python_version >= '3.10'alongside the existinghttpx >=0.27,<0.29. Thepython_versionmarker is a no-op under your currentrequires-pythonbut documents the floor.4. Public-API caveat.
httpx.Proxyandhttpx.URLappear inBuilder.proxy()'s annotation, so they're part of the public type surface. With Option A the resolved annotation will behttpx2.Proxy | httpx2.URLwhen httpx2 is installed. Duck-typing at runtime keeps user-passedhttpx.Proxyinstances working fine (httpx2 keeps the same class hierarchy), but type-checkers downstream will see a different module name. Worth a sentence in the changelog either way.5. The same TLS caveat I included in the HTTPXodus issue template applies to PTB: httpx2 verifies against the OS trust store instead of
certifi, so containerised and corporate-proxy users will see different behaviour. Flagging it here since PTB users span a wide range of deployment environments.6. If the "different networking backends" angle is the actual plan (e.g. aiohttp or a custom transport), that's totally fair — Option A is opt-in and doesn't preclude it. I just want to make sure
python-telegram-bot[http2]and[socks]continue to work under whichever path you pick.7. Ready to open the PR. The HTTPXodus bot migration in mem0 (issue #7207) and the AutoGPT one (PR #14271) both follow the dual-import pattern and pass their full test suites. Happy to mirror that here — diff would be ~8 files, all 4 of the affected tests would import
httpx2to match the SUT, no test code logic changes.If you'd rather wait for httpx 1.0 stable, totally understood — I'll close my side and stop pinging. Just wanted to make sure the option was visible alongside the other backends @harshil21 mentioned. 🙏
SiAgentBuild commentedon Sep 3, 2026
refactor: migrate httpx to httpx2 with dual import
fix: complete the hard switch