pathlib is an interesting, object-oriented take on the filesystem paths. With plenty of functions to create, delete, move, rename, read, write, find, or split files, pathlib is an excellent replacement for the os module. But is it faster?
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.
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.