Re: [path-PEP] Path inherits from basestring again

On Fri, 29 Jul 2005 14:48:55 +1200, Tony Meyer <t-meyer@ihug.co.nz> wrote:
>
>Would you really choose this:
>
> p = Path() / "build" / "a" / "very" / "very" / "long" / "path"
>
>Over this:
>
> p = Path(os.path.join("build", "a", "very", "very", "long", "path"))

Or have the constructor accept multiple arguments.

>? A saving of six characters, and the second one is a lot clearer. If
>there was a os.path.joinPath (or whatever name) function that returned a
>Path object rather than a string, then you'd get:
>
> p = joinPath("build", "a", "very", "very", "long", "path")

Indeed.

I have a little function I've written called normalizePath(). It
expands users ("~" and "~someuser"), does os.path.join(), then gets
the absolute path (os.path.abspath()) of the result. The code is
trivial:

def normalizePath(p, *pathParts):
   """ Normalize a file path, by expanding the user name and getting
   the absolute path..
   @param p [string] = a path to a file or directory
   @param pathParts [list of string] = optional path parts
   @return [string] = the same path, normalized
   """
   p1 = os.path.abspath(os.path.expanduser(p))
   if len(pathParts)>0:
      allPathParts = [ p1 ]
      allPathParts.extend(pathParts)
      p1 = os.path.join(*allPathParts)
   p2 = os.path.abspath(p1)
   return p2
normalisePath=normalizePath # alternate spelling
join=normalizePath # it works like os.path.join, but better

To be honest I don't see the point of having a Path class. That's
the way Java does it, and I find path handling in Java to be a lot
more of a hassle than in Python. (Actually, most things are more of
a hassle in Java, but that's another story).

-- 
Email: zen19725 at zen dot co dot uk