gh-91061: also accept pathlib.Path for winsound.PlaySound

[moribellamy]

No description provided.

[ghost]

All commit authors signed the Contributor License Agreement.

[arhadthedev]

While the autolinker bot is being enhanced, here is a link so the readers of the PR can jump here via an autogenerated line back there: gh-91061.

[moribellamy]

@JelleZijlstra any more comments? i updated the error message since you last looked.

[JelleZijlstra]

Minor fix:

Suggested change

	"'sound' must be str, os.PathLike, or None; not '%s'",
	"'sound' must be str, os.PathLike, or None, not '%s'",

Bigger question: What if we have a subclass of bytes that also is a PathLike resolving to a str? How is that case handled elsewhere?

[moribellamy]

AFAIK the PathLike in test_winsound.py::PlaySoundTest.test_snd_filepath() (on line 129) resolves to str, so we have that covered

[JelleZijlstra]

That one isn't a bytes subclass.

[moribellamy]

i see. an object fitting that description would pass straight through PyOS_FSPath, without calling fspath on it first. open() would exhibit the same behavior, since open() passes a pyobject to PyOS_FSPath as well without checking for this case.

[moribellamy]

see _io_open_impl in _iomodule.c

[moribellamy]

@JelleZijlstra to recap, open() would treat that kind of object by looking at the bytes object x itself, and would not try x.__fspath__(). this code, as it stands, does the same thing. what should we do?