`zipfile.ZipFile.writestr()` raises `AttributeError` instead of accepting `os.PathLike` objects (e.g. `pathlib.Path`)

[Builder106]

Bug report

Bug description:

Unlike ZipFile.write() (which accepts os.PathLike objects such as pathlib.Path for both its filename and arcname arguments), ZipFile.writestr() fails when passed a PathLike object as its zinfo_or_arcname parameter.

Instead of converting it to a string using os.fspath() (as expected by modern standard library conventions), it attempts to call .find(chr(0)) directly on the path object, resulting in an immediate AttributeError.

Repro:

import zipfile
import pathlib
import io
z = zipfile.ZipFile(io.BytesIO(), 'w')
# Passes a pathlib.Path instead of a raw string
z.writestr(pathlib.Path('foo.txt'), b'hello')

Traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../zipfile/__init__.py", line 2020, in writestr
    zinfo = ZipInfo(zinfo_or_arcname)._for_archive(self)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../zipfile/__init__.py", line 455, in __init__
    filename = _sanitize_filename(filename)
  File ".../zipfile/__init__.py", line 410, in _sanitize_filename
    null_byte = filename.find(chr(0))
                ^^^^^^^^^^^^^
AttributeError: 'PosixPath' object has no attribute 'find'

CPython versions tested on:

3.14

Operating systems tested on:

macOS

[picnixz]

It's kinda documenteed though:

zinfo_or_arcname is either the file name it will be given in the archive, or a ZipInfo instance

And semnatically it doesn't make sense to pass a path here (at least to me). write() uses filename for reading and I would however say that passing a Path as arcname is the weird part. But we can consider it as a feature (I'm not really against). However it's not a bug IMO.

cc @jaraco

[Builder106]

Hey @picnixz.

I get why passing a Path for arcname might feel semantically weird since it's just a name inside the archive, but people actually use pathlib all the time to build up virtual/logical paths (like Path("logs") / "output.txt"). It's super handy for archive names since it saves you from messy string concatenations or os.path.join calls.

Also, ZipFile.write() already accepts a Path object for arcname right now. It accidentally works because ZipInfo.from_file() passes the argument through os.path.splitdrive(), which implicitly stringifies it. So right now we have a slightly annoying API inconsistency where .write() takes a Path but .writestr() crashes.

If we just drop an os.fspath() cast into ZipInfo.__init__() or _sanitize_filename(), it fixes the crash and brings .writestr() perfectly in line with both .write() and modern PEP 519 expectations.

[picnixz]

And thus for me it does not mean we necessarily need this. I leave it to Jason but I would rather leave it as is. It is still not a bug. I still consider this feature as non-necessary and just a convience but the behavior is documented. Calling fspath() has a minor cost and has the wrong semantics in this case IMO.

I do not consider write() accepting a Path by accident as a compelling reason. There are other cases of such behavior in the stdlib where the documented behavior extends implicitly to larger class of inputs.

[Builder106]

K, fair enough. I'll concede it as a convenience feature rather than a strict bug. I just find myself building archive paths with pathlib so often these days that having to wrap them in str() feels like a papercut, especially when .write() spoils us by handling it automatically.

I'll leave it to Jason's judgement on whether the DX improvement is worth the os.fspath() overhead. Happy to write the patch if so.