[Python-Dev] PEP 355 status

[Talin]

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.