[Python-Dev] PEP 355 status

[Greg Ewing]

Talin wrote:
> (Actually, the OOP approach has a slight advantage in terms of the 
> amount of syntactic sugar available,

Even if you don't use any operator overloading, there's
still the advantage that an object provides a namespace
for its methods. Without that, you either have to use
fairly verbose function names or keep qualifying them
with a module name. Code that uses the current path
functions tends to contain a lot of
os.path.this(os.path.that(...)) stuff which is quite
tedious to write and read.

Another consideration is that having paths be a
distinct data type allows for the possibility of file
system references that aren't just strings. In
Classic MacOS, for example, the definitive way of
referencing a file is by a (volRefum, dirID, name)
tuple, and textual paths aren't guaranteed to be
unique or even to exist.

> (I should not that the Java Path API does *not* follow my scheme of 
> separation between locators and inodes, while the C# API does, which is 
> another reason why I prefer the C# approach.)

A compromise might be to have all the "path algebra"
operations be methods, and everything else functions
which operate on path objects. That would make sense,
because the path algebra ought to be a closed set
of operations that's tightly coupled to the platform's
path semantics.

--
Greg