You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
All standard library functions accepting str paths must accept PathLike as well #102425
Inspired by gh-3484 that tried to fix this for wave.open() only but failed.
We need a centralized and universal approach instead so everything accepting str paths could automatically accept PathLike for free.
For this, we can amend stdlib functions to wrap their path arguments into pathlib.PurePath introduced in Python 3.4. Unlike os.fspath, it throws a nicely formatted exception for us:
changed the title [-]All std methods and functions accepting `str` paths must accept `PathLike` as well[/-][+]All standard library functions accepting `str` paths must accept `PathLike` as well[/+]on Mar 4, 2023
We need a centralized and universal approach instead so everything accepting str paths could automatically accept PathLike for free.
os.fspath is meant to do just that.
Note that importing pathlib and creating PurePath are relatively expensive operations (compared to os.fspath with strings). When the niceties they provide aren't useful, it's better to avoid them.
Unlike os.fspath, it throws a nicely formatted exception for us:
How can the error message from os.fspath be improved?
No need to reopen this for my comment on #103659 , I tried to say that this issue is not a reason for changing the behaviour of os.environ with PathLike objects.
The purpose of this issue is not clear. os.fspath() already has a clear error message. The caller can override it if it supports more types (for example, open file descriptors or open file objects). I do not see how using the pathlib.PurePath constructor can make this better. More, os.fspath() is more lightweight and faster than pathlib.PurePath().
Activity
[-]All std methods and functions accepting `str` paths must accept `PathLike` as well[/-][+]All standard library functions accepting `str` paths must accept `PathLike` as well[/+]ericvsmith commentedon Mar 4, 2023
It’s not clear to me what you’re proposing to change. Can you provide specifics?
How would
PurePath(16)’s behavior change?encukou commentedon Mar 6, 2023
os.fspathis meant to do just that.Note that importing
pathliband creatingPurePathare relatively expensive operations (compared toos.fspathwith strings). When the niceties they provide aren't useful, it's better to avoid them.How can the error message from
os.fspathbe improved?hauntsaninja commentedon Mar 7, 2023
I'm confused,
pathlib.PurePath's error message in the thing you've posted is literally coming straight fromos.fspatharhadthedev commentedon Apr 21, 2023
Closing in favor of gh-103659.
arhadthedev commentedon Apr 21, 2023
Reopening after #103659 (comment):
However, I'll return to this issue much later.
ronaldoussoren commentedon Apr 21, 2023
No need to reopen this for my comment on #103659 , I tried to say that this issue is not a reason for changing the behaviour of
os.environwith PathLike objects.serhiy-storchaka commentedon Nov 3, 2025
The purpose of this issue is not clear.
os.fspath()already has a clear error message. The caller can override it if it supports more types (for example, open file descriptors or open file objects). I do not see how using thepathlib.PurePathconstructor can make this better. More,os.fspath()is more lightweight and faster thanpathlib.PurePath().efimov-mikhail commentedon Nov 3, 2025
@serhiy-storchaka , "not planned" suits better, isn't it?