• o11c@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    The problem with pathlib is that it normalizes away critical information so can’t be used in many situations.

    ./path should not be path should not be path/.

    Also the article is wrong about “Path('some\\path') becomes some/path on Linux/Mac.”

    • techwizrd@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Can you explain these a little more? I don’t understand what that breaks. Also, shouldn’t the second one be correct if you use a raw string?

      • o11c@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        All of these can be done with raw strings just fine.

        For the first pathlib bug case, PATH-like lookup is common, not just for binaries but also data and conf files. If users explicitly request ./foo they will be very upset if your program instead looks at /defaultpath/foo. Also, God forbid you dare pass a Path("./--help") to some program. If you’re using os.path.dirname this works just fine.

        For the second pathlib bug case, dir/ is often written so that you’ll cause explicit errors if there’s a file by that name. Also there are programs like rsync where the trailing slash outright changes the meaning of the command. Again, os.path APIs give you the correct result.

        For the article mistake, backslash is a perfectly legal character in non-Windows filenames and should not be treated as a directory component separator. Thankfully, pathlib doesn’t make this mistake at least. OTOH, / is reasonable to treat as a directory component separator on Windows (and some native APIs already handle it, though normalization is always a problem).

        I also just found that the pathlib.Path constructor ignores extra kwargs. But Python has never bothered much with safety anyway, and this minor compared to the outright bugs the other issues cause.