[Python-Dev] The path module PEP

[Paul Moore]

On 1/25/06, BJörn Lindqvist <bjourne at gmail.com> wrote:
> My comments on the issues. It was easier this way than trying to reply
> on every message individually.
>
> Inheritance from string (Jason)
>
> This issue has been brought up before when people were discussing the
> path module. I think the consensus is that, while the inheritance
> isn't pure, practicality beats purity. It would require to big changes
> to Python and would break to much existing code to not extend string.
>
> I'll add this to Resolved Issues if nobody minds.

I mind (see my previous post)...

> Remove __div__ (Ian, Jason, Michael, Oleg)
>
> This is one of those where everyone (me too) says "I don't care either
> way." If that is so, then I see no reason to change it unless someone
> can show a scenario in which it hurts readability. Plus, a few people
> have said that they like the shortcut.

Hardly. I've seen some pretty strong arguments (both for and against)
- not what I'd describe as everyone saying they don't care.

FWIW, I find the / operator ugly. Also, multiple concatenation (path /
"a" / "b" / "c") results in building lots of intermediates, where
path.join("a", "b", "c") need not. Arguing that you can't reuse string
methods is bogus, IMHO, as the requirement to subclass from string is
far from clear.

Actually, reading that, I'd suggest:
- an append() method to add extra components to a path
- a multi-arg Path() constructor

So, we have
- path.append("a", "b", "c")
- Path("C:", "Windows", "System32")

Quick question - how do Path objects constructed from relative paths
behave? Are there such things as relative path objects? Consider

    p1 = Path("a")
    p2 = Path("b")

Is p1.append(p2) (or p1/p2) legal? What does it mean? I'd have to
assume it's the same as Path("a", "b"), but I'm not sure I like
that... What about Path("/a").append(Path("/b")) ???

Also note that my example Path("C:", "Windows", "System32") above is
an *absolute* path on Windows. But a relative (albeit stupidly-named
:-)) path on Unix. How would that be handled?

Not that os.path gets it perfect:

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.join("C:", "Windows", "System32")
'C:Windows\\System32'
>>> os.path.join(".", os.path.join("C:", "Windows", "System32"))
'.\\C:Windows\\System32'
>>>

But os.path manipulates strings representing pathnames (and I can
forgive oddities like this by noting that some rules about pathnames
are pretty subtle...). I'd have higher standards for a dedicated Path
object.

Arguably, Path objects should always maintain an absolute path - there
should be no such thing as a relative Path. So you would have

    str(Path("whatever")) === os.path.abspath("whatever")

It also allows Path("C:", "Windows") to do different things on Windows
and Unix (absolute on Windows, relative to os.curdir on Unix).

This would imply that Path("a", a_path) or a_path.append(another_path)
is an error. And of course, for this to work, Path objects *can't* be
a subclass of string... :-)

Paul.