fix(files): normalize PathLike upload tuples

[pranjalbhatia710]

Summary

• normalize multipart upload tuples before final file-content handling
• convert PathLike tuple contents with the same read path used for direct file uploads
• add sync and async regression coverage for (filename, PathLike) tuples, including metadata tuples

Fixes #3473.

Tests

uv run --with dirty-equals --with pytest --with pytest-asyncio --with pytest-xdist --with ruff pytest -p no:benchmark tests/test_files.py -q
# 18 passed in 2.12s

uv run --with ruff ruff check src/openai/_files.py tests/test_files.py
# All checks passed!

git diff --check
# no output

Note: uv run --frozen pytest -p no:benchmark tests/test_files.py -q could not collect because the frozen environment did not include dirty_equals, so I used explicit --with dev-test dependencies for the focused validation.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3c800d5ae6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve tuple FileTypes in extracted uploads

This narrowed guard is also used by assert_is_file_content() inside extract_files() before generated resource methods call to_httpx_files(); those public methods accept FileTypes, whose documented type includes tuple forms. As a result, calls like client.files.create(file=("data.jsonl", b"..."), purpose="batch") or audio/image uploads with a custom filename/content type now raise RuntimeError during extraction instead of reaching the new tuple-normalization path, so the regression affects normal multipart endpoints rather than only direct to_httpx_files() callers.

Useful? React with 👍 / 👎.

[pranjalbhatia710]

Thanks — good catch. I pushed 2f0860ff to keep extract_files() accepting tuple-shaped FileTypes, so generated multipart endpoints can still pass (filename, bytes/path, content_type) through to the tuple-normalization path.

Validation:

.venv/bin/python -m pytest tests/test_files.py -q
# 19 passed in 2.81s
.venv/bin/ruff check src/openai/_files.py tests/test_files.py
# All checks passed!
git diff --check
# no output

[amirhosseinghanipour]

Functionally this achieves the same fix as #3474/#3500. Either shape is fine.

[jbeckwith-oai]

Clean at 2f0860ff319e8b8119d0e32566831f24a4a25cfc. The change restores the intended tuple-normalization path while keeping tuple uploads accepted by extract_files(), and the sync/async regressions cover both two- and three-element tuple shapes. I found no correctness, boundary, or maintainability blockers.

Validation: tests/test_files.py plus tests/test_extract_files.py passed (29/29); changed-file Ruff lint and format checks passed; full Pyright passed with the project virtualenv; full mypy passed; and git diff --check passed.