On Nov 2, 2006, at 6:53 PM, Talin wrote:
Ronald Oussoren wrote:On Nov 2, 2006, at 5:21 PM, Paul Moore wrote:On 11/1/06, Mike Orr <[EMAIL PROTECTED]> wrote:[...] especially since both Mac and Windows do the right thing with "/", "..", and "." now.Not always: D:\Data>dir C:/ Invalid switch - "".And on Mac this depends on the API you use, if you use the Carbon API'syou still have to use colons as directory separators (and the OS doesthe correct translation for you, which is why you can still have a filenamed "a/b" in the Finder).I think you folks are missing the point here - of *course* different platforms have different interpretations of path separators.But that's not what we're talking about here - we are talking about thebehavior of os.path.normpath().Look, people have been writing cross-platform Python code for years. Howis this possible when different platforms have such a radical interpretation of path strings? The answer is that Python's path manipulation functions are *better* than what the underlying platformsupplies. os.path doesn't just slavishly copy the semantics of the localfilesystem, it is far more generous (and more useful). Using os.path.normpath(), one is able to manipulate path strings in a cross-platform way. So if say: os.path.normpath( os.path.join( __file__, "../../lib" )...what I get on both Win32, Linux and OSX (I can't speak for any otherplatform) is exactly the same semantics.
That happens to work because all tree use '..' to represent a parent directory and happen to accept forward slashes as a directory seperator. Your example doesn't work when you use macpath to manipulate classic OS9-style paths.
I agree that the functions in os.path are a good abstraction for platform-independent path manipulation, even if your example is not. A better cross-platform way to write the call above is: os.path.join( os.path.dirname( os.path.dirname( os.path.abspath (__file__)))).
And as far as things like os.pardir goes - you can't put 'os.pardir' in a configuration file! There are *lots* of applications where you want toshare data files across platforms, and not have to revise the path strings every time you migrate between Unix and Win32. In fact, I'll tell you a little secret about Win32 applications - although "officially" the path separator for Win32 is backslash, there are so many Unix and cross-platform programs ported to Win32 that a larger percentage of the programs available on Win32 accept paths in either format.
Most windows APIs accept either separator, but IIRC the actual kernel API uses backslashes only, which leaks through at some points. It has been a while since I last looked at this (and scared collegues who's code I was testing), but I think it was the "really" absolute paths that don't accept forward slashes (paths like \\.\C:\Windows). This was with NT 4 and from the top of my head, so I may well be wrong.
So lets not get bogged down in the strange quirks of how a particular platform interprets paths - I am much more interested in being able to combine paths together in an intuitive way, and have it "just work" on all platforms. And that includes path strings read from config files, not just path objects.
If you want that you'll have to define some way to convert between a generic path representation to the native one.
Ronald, who doesn't really want to get sucked into this discussion.P.S. I agree with the sentiment that several others have raised: please work on a better os.path as a seperate library and come back when that has proven itself in the field.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
