Nick Coghlan wrote:
Talin wrote:
Part 3: Does this mean that the current API cannot be improved?
Certainly not! I think everyone (well, almost) agrees that there is much room for improvement in the current APIs. They certainly need to be refactored and recategorized.
But I don't think that the solution is to take all of the path-related functions and drop them into a single class, or even a single module.
+1 from me.
(for both the fraction I quoted and everything else you said, including the locator/inode/file distinction - although I'd also add that 'symbolic link' and 'directory' exist at a similar level as 'file').
I would tend towards classifying directory operations as inode-level operations, that you are working at the "filesystem as graph" level, rather than the "stream of bytes" level. When you iterate over a directory, what you are getting back is effectively inodes (well, directory entries are distinct from inodes in the underlying filesystem, but from Python there's no practical distinction.) If I could draw a UML diagram in ASCII, I would have "inode --> points to --> directory or file" and "directory --> contains * --> inode". That would hopefully make things clearer. Symbolic links, I am not so sure about; In some ways, hard links are easier to classify. --- Having done a path library myself (in C++, for our code base at work), the trickiest part is getting the Windows path manipulations right, and fitting them into a model that allows writing of platform-agnostic code. This is especially vexing when you realize that its often useful to manipulate unix-style paths even when running under Win32 and vice versa. A prime example is that I have a lot of Python code at work that manipulates Perforce client specs files. The path specifications in these files are platform-agnostic, and use forward slashes regardless of the host platform, so "os.path.normpath" doesn't do the right thing for me.
Cheers, Nick.