The problem with
pathlib
is that it normalizes away critical information so can't be used in many situations../path
should not bepath
should not bepath/
.Also the article is wrong about "
Path('some\\path')
becomessome/path
on 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
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 aPath("./--help")
to some program. If you're usingos.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 likersync
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.