[Python-3000] Path Reform: Get the ball rolling

[Ronald Oussoren]

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 <sluggoster at gmail.com> 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's
>> you still have to use colons as directory separators (and the OS does
>> the correct translation for you, which is why you can still have a  
>> file
>> named "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  
> the
> behavior of os.path.normpath().
>
> Look, people have been writing cross-platform Python code for  
> years. How
> is 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 platform
> supplies. os.path doesn't just slavishly copy the semantics of the  
> local
> filesystem, 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  
> other
> platform) 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 to
> share 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20061102/3cbbb84b/attachment.bin