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.