[Python-Dev] PEP 355 status

[Talin]

Greg Ewing wrote:
> 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.

Given the flexibility that Python allows in naming the modules that you 
import, I'm not sure that this is a valid objection -- you can make the 
module name as short as you feel comfortable with.

> 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.

That's true of textual paths in general - i.e. even on unix, textual 
paths aren't guaranteed to be unique or exist.

Its been a while since I used classic MacOS - how do you handle things 
like configuration files with path names in them?

>> (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.

Personally, this is one of those areas where I am strongly tempted to 
violate TOOWTDI - I can see use cases where string-based paths would be 
more convenient and less typing, and other use cases where object-based 
paths would be more convenient and less typing.

If I were designing a path library, I would create a string-based system 
as the lowest level, and an object based system on top of it (the reason 
for doing it that was is simply so that people who want to use strings 
don't have to suffer the cost of creating temporary path objects to do 
simple things like joins.) Moreover, I would keep the naming conventions 
of the two systems similar, if at all possible possible - thus, the 
object methods would have the same (short) names as the functions within 
the module.

So for example:

    # Import new, refactored module io.path
    from io import path

    # Case 1 using strings
    path1 = path.join( "/Libraries/Frameworks", "Python.Framework" )
    parent = path.parent( path1 )

    # Case 2 using objects
    pathobj = path.Path( "/Libraries/Frameworks" )
    pathobj += "Python.Framework"
    parent = pathobj.parent()

Let me riff on this just a bit more - don't take this all too seriously 
though:

    Refactored organization of path-related modules (under a new name
    so as not to conflict with existing modules):

    io.path -- path manipulations
    io.dir -- directory functions, including dirwalk
    io.fs -- dealing with filesystem objects (inodes, symlinks, etc.)
    io.file -- file read / write streams

    # Import directory module
    import io.dir

    # String based API
    for entry in io.dir.listdir( "/Library/Frameworks" ):
       print entry  # Entry is a string

    # Object based API
    dir = io.dir.Directory( "/Library/Frameworks" )
    for entry in dir: # Iteration protocol on dir object
       print entry  # entry is an obj, but __str__() returns path text

    # Dealing with various filesystems: pass in a format parameter
    dir = io.dir.Directory( "/Library/Frameworks" )
       print entry.path( format="NT" ) # entry printed in NT format

    # Or you can just use a format specifier for PEP 3101 string format:
    print "Path in local system format is {0}".format( entry )
    print "Path in NT format is {0:NT}".format( entry )
    print "Path in OS X format is {0:OSX}".format( entry )

Anyway, off the top of my head, that's what a refactored path API would 
look like if I were doing it :)

(Yes, the names are bad, can't think of better ATM.)

-- Talin