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