I hadn't heard of it either, although I have played with Twisted's FilePath[1] class previously.
I didn't really understand the attraction of an OO filesystem API until I actually used it in anger and realised how handy it was that all the relevant functions were on the object I was messing with, instead of arbitrarily divided between the "os" and "os.path" modules.
Some (hopefully constructive) suggestions for the pathlib API:
- Python 3 dicts ditched .iterkeys(), .itervalues() and .iteritems(); why does pathlib use the clumsy .iterdir() when it could just be called .children?
- Like many Python programmers (I assume), I'm more familiar with POSIX command-line tools than I am with POSIX APIs. Command-line tools generally have an option to control whether they dereference symlinks (cp -L, find -L, etc) rather than having a separate. parallel tool that does the same thing. I think it would be neater if .lstat() and .lchmod() were removed in favour of a "follow_symlinks" parameter to .stat() and .chmod() (and .is_dir() and .touch() and .owner(), and, and, and..)
- If you're going to have convenience functions that pick out interesting bits from the .stat() return value, I would find .size() far more practical than .is_socket()
Concrete paths inherit from pure paths - this would be quite strange using antonyms. This isn't like an "abstract" base class. It's a full class on its own, which is extended by another.
Anyway, I think it's meant to be "pure" like pure functions, generally having no side effects or external inputs.
i think so too. like it says in the docs: "Regardless of the system you’re running on, you can instantiate all of these classes, since they don’t provide any operation that does system calls." http://docs.python.org/3.4/library/pathlib.html#pure-paths
I thought operator overloading like that was considered bad practise. It seems to me that the + operator should have been overloaded, not the / operator.