gh-91061: also accept pathlib.Path for winsound.PlaySound #91489
Conversation
|
All commit authors signed the Contributor License Agreement. |
|
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. |
|
@JelleZijlstra any more comments? i updated the error message since you last looked. |
PC/winsound.c
Outdated
| @@ -94,17 +94,25 @@ winsound_PlaySound_impl(PyObject *module, PyObject *sound, int flags) | |||
| return NULL; | |||
| } | |||
| wsound = (wchar_t *)view.buf; | |||
| } else if (PyBytes_Check(sound)) { | |||
| PyErr_Format(PyExc_TypeError, | |||
| "'sound' must be str, os.PathLike, or None; not '%s'", | |||
There was a problem hiding this comment.
Minor fix:
| "'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?
There was a problem hiding this comment.
AFAIK the PathLike in test_winsound.py::PlaySoundTest.test_snd_filepath() (on line 129) resolves to str, so we have that covered
There was a problem hiding this comment.
That one isn't a bytes subclass.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
see _io_open_impl in _iomodule.c
There was a problem hiding this comment.
@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?
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
No description provided.