[Python-Dev] Path object design

[Greg Ewing]

glyph at divmod.com wrote:

>    >>> os.path.join("hello", "slash/world")
>    'hello/slash/world'
>    >>> os.path.join("hello", "slash//world")
>    'hello/slash//world'
>    Trying to formulate a general rule for what the arguments to 
> os.path.join are supposed to be is really hard.

If you're serious about writing platform-agnostic
pathname code, you don't put slashes in the arguments
at all. Instead you do

   os.path.join("hello", "slash", "world")

Many of the other things you mention are also a
result of not treating pathnames as properly opaque
objects.

If you're saying that the fact they're strings makes
it easy to forget that you're supposed to be treating
them opaquely, there may be merit in that view. It
would be an argument for making path objects a
truly opaque type instead of a subclass of string
or tuple.

>  * although individual operations are atomic, shutil.copytree and 
> friends aren't.  I've often seen python programs confused by 
> partially-copied trees of files.

I can't see how this can be even remotely regarded
as a pathname issue, or even a filesystem interface
issue. It's no different to any other situation
where a piece of code can fall over and leave a
partial result behind. As always, the cure is
defensive coding (clean up a partial result on error,
or be prepared to tolerate the presence of a previous
partial result when re-trying).

It could be argued that shutil.copytree should clean
up after itself if there is an error, but that might
not be what you want -- e.g. you might want to find
out how far it got, and maybe carry on from there
next time. It's probably better to leave things like
that to the caller.

--
Greg