[Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

At 08:29 PM 6/26/2005 -0500, Skip Montanaro wrote:

>     Phillip> ... but have a different name (like the 'parent' property that
>     Phillip> is os.path.dirname in disguise) ...
>
>     Phillip> ... (like the 'listdir()' method that returns full paths rather
>     Phillip> than just filenames).
>
>     Skip> To the extent that the path module tries to provide a uniform
>     Skip> abstraction that's not saddled with a particular way of doing
>     Skip> things (e.g., the Unix way or the Windows way), I don't think this
>     Skip> is necessarily a bad thing.
>
>     Phillip> I'm confused by your statements.  First, I didn't notice the
>     Phillip> path module providing any OS-abstractions that aren't already
>     Phillip> provided by os.path.  Second, using inconsistent and confusing
>     Phillip> names is pretty much always a bad thing.  :)
>
>Sorry, let me be more explicit.  "dirname" is the Unix name for "return the
>parent of this path".  In the Windows and Mac OS9 worlds (ignore any
>possible Posix compatibility for a moment), my guess would be it's probably
>something else.  I suspect listdir gets its "return individual filenames
>instead of full paths" from the semantics of the Posix opendir/readdir/
>closedir functions.  If it makes more sense to return strings that represent
>full paths or new path objects that have been absolute-ified, then the minor
>semantic change going from os.path.listdir() to the listdir method of
>Jason's path objects isn't a big problem to me.

The semantics aren't the issue; it's fine and indeed quite useful to have a 
method that returns path objects.  I'm just saying it shouldn't be called 
listdir(), since that's confusing when compared to what the existing 
listdir() function does.  If you look at my original post, you'll see I 
suggested it be called 'subpaths()' instead, to help reflect that it 
returns paths, rather than filenames.