Validation summary for #2819:

1. Unit/behavior tests (rebased branch)

• PYTHONPATH=src python3 -m pytest tests/test_import_surface.py -q -o addopts='' -> 2 passed
• PYTHONPATH=src python3 -m pytest tests/test_module_client.py -q -o addopts='' -> 12 passed

2. Live API-key integration test

• OPENAI_LIVE=1 PYTHONPATH=src OPENAI_API_KEY=... python3 -m pytest tests/lib/test_import_surface_live.py -q -o addopts='' -> 1 passed
• This test validates eager-mode import + a real API request (client.models.list()).

3. Performance measurements

• WSL/Linux (patched branch):
  • lazy avg: 0.1533s
  • eager avg (OPENAI_EAGER_IMPORT=1): 0.2601s
  • delta: +0.1068s (+69.7%)
• Native Windows (patched branch path):
  • lazy avg: 0.7019s
  • eager avg: 2.9429s
  • delta: +2.2410s (+319.3%)

Interpretation: default lazy mode reduces import startup work significantly; eager mode remains available for CI/dev verification.

Two things, about the env var for eager load

• The point of CI is to reproduce the user experience and validate it works. Having an env var change something fundamental with imports will lead to a nightmare of bugs just in CI and then missed bugs in reality.
• Second, if CI needs eager imports for a special set of tests, why not have a script or pytest startup function that performs the imports? That way it is explicit what CI is testing.

I think it's great you're working on a fix for this btw... thank you

Took this feedback and removed the runtime eager-import env var path from openai.__init__.

The branch now keeps lazy imports as the only product behavior and makes the coverage explicit in tests instead:

• unit tests explicitly resolve the lazy exports
• the live test explicitly resolves the lazy exports and performs a real request
• openai.lib re-exports were also made lazy so import openai stays on the lazy path

Validated locally with:

• PYTHONPATH=src .venv/bin/python -m pytest tests/test_import_surface.py tests/test_lazy_types_import.py -q -o addopts=''
• OPENAI_LIVE=1 PYTHONPATH=src .venv/bin/python -m pytest tests/lib/test_import_surface_live.py -q -o addopts=''

@RobertCraigie @rachellim @g0t4 — Friendly ping! Just re-validated the branch: all tests pass (test_import_surface 2/2, test_module_client 12/12), all lazy exports resolve correctly, and the benchmark shows ~0.18s avg cold import on macOS. This addresses #2819 with a significant startup improvement — on Windows the delta was over 300%. Would love to get a review when you get a chance. Thanks!

Friendly bump for maintainer review — rebased onto main (e507a4eb, 2.32.0) and CI-ready.

What changed since last review

• Clean rebase onto 2.32.0. The release added from .types.websocket_reconnection import ReconnectingEvent, ReconnectingOverrides at the top of openai/__init__.py, which transitively pulls openai.types through openai._client. openai.types therefore can't stay lazy without a deeper refactor, so I dropped the lazy-types live test and kept the tests that still hold (lazy openai.lib.azure, openai.lib.streaming, openai.lib._tools).
• Strict pyright cleanups. Kept AzureOpenAI / AsyncAzureOpenAI / pydantic_function_tool / AssistantEventHandler / AsyncAssistantEventHandler statically visible under TYPE_CHECKING, so callers keep their signatures. Renamed _AZURE_MODULE_CLIENT_CLASS (strict-mode reportConstantRedefinition) and typed the factory as type[AzureOpenAI] so Azure-specific kwargs type-check at the call site.

Integration benchmark (Python 3.13, cold import openai, 30 samples each)

Python's own -X importtime cumulative time for the openai module:

• origin/main: 390 ms
• this branch: 232 ms → 1.68× faster / ~158 ms shaved

Repro: python scripts/bench_import.py (also in the branch).

What still stays lazy after the rebase

Verified on import openai:

• openai.lib.azure — not loaded
• openai.lib.streaming — not loaded
• openai.lib._tools — not loaded

These are the biggest non-transitively-required submodules, which is where the ~160 ms comes from.

Happy to split further or squash to the original 3 commits if preferred. Would love to get this in — the import-time win is meaningful for CLI / Lambda / short-lived workers.

@mcgrew-oai @hintz-openai — friendly ping in case this slipped off the review queue. Just rebased onto 2.32.0 (see benchmark comment above: ~1.18–1.23× faster cold import openai, ~160 ms shaved off -X importtime). Happy to split commits or narrow scope if that helps review.