AttributeError: 'WindowsPath' object has no attribute 'read'

[kannanwisen]

Description

The file= parameter of client.beta.files.upload() is annotated as FileTypes, which includes Tuple[Optional[str], FileContent], and FileContent includes os.PathLike. Based on that, passing a filename together with a Path object should be valid — and it passes type checking.

At runtime it fails with an AttributeError.

Repro

from pathlib import Path
from anthropic import Anthropic

client = Anthropic()

path = Path("Wisen.pdf")
file_obj = client.beta.files.upload(file=("Wisen-IT-Solutions.pdf", path))

Actual

AttributeError: 'WindowsPath' object has no attribute 'read'

Expected

One of:

• the Path is read and uploaded (consistent with passing a bare Path, which works fine), or
• a clear SDK-level error explaining that a Path is not supported inside the tuple form.

The current AttributeError doesn't mention the SDK, the file= parameter,
or what was wrong with the input, which makes it hard to diagnose.

Working alternatives

Passing the Path on its own works:

client.beta.files.upload(file=path)                        # OK

Passing a handle or bytes inside the tuple also works:

client.beta.files.upload(file=("Wisen-IT-Solutions.pdf", open("Wisen.pdf", "rb")))   # OK
client.beta.files.upload(file=("Wisen-IT-Solutions.pdf", path.read_bytes()))         # OK

Only the Path-inside-a-tuple combination fails.

Environment

• anthropic 0.117.0
• Windows
• Python 3.11.15

[nightcityblade]

Hi, I'd like to work on this. I'll submit a focused PR with regression coverage shortly.

[kannanwisen]

Thanks for picking this up! Happy to test on Windows / Python 3.11.15 once it lands.

[rehan243]

oh man, I hit this exact thing a while ago, just with Path objects in a different SDK. It's super misleading, cause type hints make it look fine and then you get slapped with 'WindowsPath has no attribute read', not gonna lie, took me a minute to figure out why the tuple form exploded.

I dug into anthropic-sdk-python's source and yeah, it expects the second element in the tuple to be a file-like object with .read, or raw bytes. Path objects don't have .read, so it just blows up at runtime. The docs kinda gloss over that detail.

Just to show, this works for me:

with open(path, "rb") as f:
    client.beta.files.upload(file=("Wisen-IT-Solutions.pdf", f))

Or you can do path.read_bytes() like you mentioned, but the tuple form wants bytes or a file handle, not a Path.

Honestly, the SDK should throw a cleaner error if you hand it a Path inside a tuple, maybe something like 'expected bytes or file-like, got Path'. I've seen this pattern trip up folks in other file APIs too.

Curious, are you using the tuple form to set a custom filename, or do you need to stream big files? I've been doing both, but mostly stick to file handles for chunked uploads.