The problem with
pathlibis that it normalizes away critical information so can’t be used in many situations../pathshould not bepathshould not bepath/.Also the article is wrong about “
Path('some\\path')becomessome/pathon Linux/Mac.”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?
All of these can be done with raw strings just fine.
For the first
pathlibbug case,PATH-like lookup is common, not just for binaries but also data and conf files. If users explicitly request./foothey will be very upset if your program instead looks at/defaultpath/foo. Also, God forbid you dare pass aPath("./--help")to some program. If you’re usingos.path.dirnamethis works just fine.For the second
pathlibbug case,dir/is often written so that you’ll cause explicit errors if there’s a file by that name. Also there are programs likersyncwhere the trailing slash outright changes the meaning of the command. Again,os.pathAPIs 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,
pathlibdoesn’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.Pathconstructor ignores extra kwargs. But Python has never bothered much with safety anyway, and this minor compared to the outright bugs the other issues cause.



