On 4/20/06, has <[EMAIL PROTECTED]> wrote:
> > >>> macpath.join('foo', 'bar')
> >':foo:bar'
>
> That said, the actual result in the above example is wrong. It should be 
> 'foo:bar', since 'foo' is an absolute path (a leading colon indicates a 
> relative path, which is not the same):

Well, no; see below.

> join('d1', 'Users')
> ':d1:Users' # wrong! (should be 'd1:Users')

The docstring for macpath.isabs() contradicts this, however:

    """On the Mac, relative paths begin with a colon,
    but as a special case, paths with no colons at all are also relative.
    Anything else is absolute (the string up to the first colon is the
    volume name)."""

This is in fact the historic interpretation of pathnames under Mac OS
before OS X (to the best of my memory -- most of the File Manager
functions that would take full pathnames were purged in Carbon). 
Under this interpretation the examples above are behaving properly. 
To get the effect has appears to expect, you would need to say e.g.
"macpath.join ('d1:', 'Users')".

> So that's pretty useless.

Well, that's open to debate.  The current documentation for macpath
just lists which operations are implemented and doesn't specify how
they're to behave.  The current implementation is consistent, at
least, if not well documented.

> More examples of brokenness:
>
> exists('d1:Users:has')
> False
> exists('/Users/has')
> True

[snip]

If d1 is the name of your system volume, then that would be a bug --
if you were explicitly calling macpath.exists() in the first case.  If
you're calling os.path.exists() under Mac OS X, then you're really
getting posixpath.exists():

>>> os.path.exists
<function exists at 0x38d70>
>>> macpath.exists
<function exists at 0x58a70>
>>> posixpath.exists
<function exists at 0x38d70>

> So the module is well broken on OS X, and has been for the last five years 
> and nobody's said or done anything about it yet.

Only if you believe it should handle HFS and POSIX paths
interchangeably.  I don't believe it's "broken", but I won't claim it
does much that's useful in the modern world other than handle
HFS-style paths (if you happen to have one for some reason).

Some interoperability functions (i.e. conversion between HFS and POSIX
paths) might be useful for the benefit of older (pre-X) scripts that
assumed HFS conventions, but the fact that no one's been clamoring for
them suggests that the need isn't very urgent today.

-- Russell Finn
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to