1. Forum
  2. Usenet
  3. COMP.LANG.PYTHON

  • File system path annotations

    From =?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=@21:1/5 to All on Mon Jun 19 10:43:38 2023
    Hello,

    what is the preferred way of annotating file system paths?

    This StackOverflow answer <https://stackoverflow.com/a/58541858/1062139>
    (and a few others) recommend using the

    str | os.PathLike

    union.

    However, byte arrays can be used as paths too, and including them
    would make the annotation quite long.

    I also believe that str confirms to the PathLike definition. Please,
    correct me if I'm wrong.

    And finally - using paths in Python programs is so common, that one
    would expect to have a special type (or type alias) in typing. Am I
    missing something?

    My apologies if I'm asking the obvious, but after some googling I came
    to the conclusion that information on this topic is surprisingly
    limited to a few StackOverflow questions.

    Best regards,

    Peter

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roel Schroeven@21:1/5 to All on Mon Jun 19 11:09:36 2023
    Op 19/06/2023 om 10:43 schreef Peter Slížik via Python-list:
    Hello,

    what is the preferred way of annotating file system paths?

    This StackOverflow answer <https://stackoverflow.com/a/58541858/1062139>
    (and a few others) recommend using the

    str | os.PathLike

    union.

    However, byte arrays can be used as paths too, and including them
    would make the annotation quite long.
    You don't have to type out the whole thing every time. Define it somewhere:

    PathLike = str | bytes | os.PathLike

    and then you can use PathLike everywhere.
    I also believe that str confirms to the PathLike definition. Please,
    correct me if I'm wrong.
    I don't think so: os.PathLike instances must have a __fspath__() method,
    which str and bytes don't have.
    And finally - using paths in Python programs is so common, that one
    would expect to have a special type (or type alias) in typing. Am I
    missing something?
    I agree there should be something like that. This StackOverflow answer (https://stackoverflow.com/a/68027757/59122) talks about something like
    that: _typeshed.AnyPath. It is used in the standard library, but
    apparently it doesn't exist at runtime and you need a trick to make it
    work. I would expect something better to exist, but as far as I can find
    out there isn't.

    PEP 519 has a little section on the topic (https://peps.python.org/pep-0519/#provide-specific-type-hinting-support):

    Provide specific type hinting support

    There was some consideration to providing a generic typing.PathLike
    class which would allow for e.g. typing.PathLike[str] to specify a type
    hint for a path object which returned a string representation.
    While potentially beneficial, the usefulness was deemed too small to
    bother adding the type hint class.

    This also removed any desire to have a class in the typing module
    which represented the union of all acceptable path-representing types as
    that can be represented with typing.Union[str, bytes,
    os.PathLike] easily enough and the hope is users will slowly
    gravitate to path objects only.

    --

    "This planet has - or rather had - a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movement of small green pieces of paper, which was odd because on the whole it wasn't the small green pieces of paper that were unhappy."
    -- Douglas Adams

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=@21:1/5 to All on Mon Jun 19 11:44:23 2023
    Thank you, Roel. You've answered all my questions.

    [PEP 519]: ...as that can be represented with typing.Union[str, bytes,
    os.PathLike] easily enough and the hope is users
    will slowly gravitate to path objects only.

    I read a lot on Python and, frankly, I don't see this happening. People on
    the Internet keep using *str* as their path representation choice.
    Presumably, programmers don't feel the need to bother with a complex
    solution if the simplest option works just fine.

    Peter

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roel Schroeven@21:1/5 to All on Mon Jun 19 16:04:16 2023
    Op 19/06/2023 om 11:44 schreef Peter Slížik:
    Thank you, Roel. You've answered all my questions.

    [PEP 519]: ...as that can be represented with typing.Union[str,
    bytes, os.PathLike] easily enough and the hope is users
    will slowly gravitate to path objects only.

    I read a lot on Python and, frankly, I don't see this happening.
    People on the Internet keep using /str/ as their path representation
    choice. Presumably, programmers don't feel the need to bother with a
    complex solution if the simplest option works just fine.
    I agree, I don't see that happening either. I often find myself using
    str for paths: often simple filenames are all that's needed, and then I
    don't see much point in importing pathlib and wrapping the filenames in
    Path() constructors. I do tend to switch to path objects when I start
    needing to do operations on the paths, though.

    --
    "Your scientists were so preoccupied with whether they could, they didn't
    stop to think if they should"
    -- Dr. Ian Malcolm

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Passin@21:1/5 to Roel Schroeven via Python-list on Mon Jun 19 11:23:00 2023
    On 6/19/2023 10:04 AM, Roel Schroeven via Python-list wrote:
    Op 19/06/2023 om 11:44 schreef Peter Slížik:
    Thank you, Roel. You've answered all my questions.

    [PEP 519]: ...as that can be represented with typing.Union[str,
    bytes, os.PathLike] easily enough and the hope is users
    will slowly gravitate to path objects only.

    I read a lot on Python and, frankly, I don't see this happening.
    People on the Internet keep using /str/ as their path representation
    choice. Presumably, programmers don't feel the need to bother with a
    complex solution if the simplest option works just fine.
    I agree, I don't see that happening either. I often find myself using
    str for paths: often simple filenames are all that's needed, and then I
    don't see much point in importing pathlib and wrapping the filenames in Path() constructors. I do tend to switch to path objects when I start
    needing to do operations on the paths, though.


    If you are writing code that will run on both Windows and Linux/Mac,
    pathlib objects are very useful since the path separators will come out
    right with no extra effort. Also, the syntax for composing a path seems
    very natural (e.g., Path('a') / 'b' / 'c'), so that's a bonus.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)