Skip to content

All standard library functions accepting str paths must accept PathLike as well #102425

Closed as not planned

Description

@arhadthedev

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:

  • os.fspath from the mentioned bpo-31412: wave.open takes a path-like object #3484:

    cpython/Lib/aifc.py

    Lines 912 to 918 in 4a82d65

    try:
    f = os.fspath(f)
    except TypeError:
    if not hasattr(f, 'read') and not hasattr(f, 'write'):
    raise TypeError('open() takes str, a path-like object, '
    + 'or an open file-like object, '
    + f'not {type(f).__name__!r}') from None

  • PurePath:

    >>> import pathlib
    >>> pathlib.PurePath(16)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "D:\Oleg\cpython\Lib\pathlib.py", line 267, in __new__
        return cls._from_parts(args)
               ^^^^^^^^^^^^^^^^^^^^^
      File "D:\Oleg\cpython\Lib\pathlib.py", line 316, in _from_parts
        drv, root, parts = self._parse_args(args)
                           ^^^^^^^^^^^^^^^^^^^^^^
      File "D:\Oleg\cpython\Lib\pathlib.py", line 300, in _parse_args
        a = os.fspath(a)
            ^^^^^^^^^^^^
    TypeError: expected str, bytes or os.PathLike object, not int

Activity

  1. added
    type-featureA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    stdlibStandard Library Python modules in the Lib/ directory
    on Mar 4, 2023
  2. 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
  3. ericvsmith commented on Mar 4, 2023

    @ericvsmith
    Member

    It’s not clear to me what you’re proposing to change. Can you provide specifics?

    How would PurePath(16)’s behavior change?

  4. encukou commented on Mar 6, 2023

    @encukou
    Member

    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?

  5. hauntsaninja commented on Mar 7, 2023

    @hauntsaninja
    Contributor

    Unlike os.fspath, it throws a nicely formatted exception for us

    I'm confused, pathlib.PurePath's error message in the thing you've posted is literally coming straight from os.fspath

  6. arhadthedev commented on Apr 21, 2023

    @arhadthedev
    MemberAuthor

    Closing in favor of gh-103659.

  7. arhadthedev commented on Apr 21, 2023

    @arhadthedev
    MemberAuthor

    Reopening after #103659 (comment):

    BTW, I don't think #102425 applies here, the os.environ values are strings some of which happen to look like paths (or integers).

    However, I'll return to this issue much later.

  8. ronaldoussoren commented on Apr 21, 2023

    @ronaldoussoren
    Contributor

    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.

  9. serhiy-storchaka commented on Nov 3, 2025

    @serhiy-storchaka
    Member

    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().

  10. efimov-mikhail commented on Nov 3, 2025

    @efimov-mikhail
    Member

    @serhiy-storchaka , "not planned" suits better, isn't it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirinterpreter-core(Objects, Python, Grammar, and Parser dirs)stdlibStandard Library Python modules in the Lib/ directorytopic-IOtype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions