On 11/9/06, Talin <[EMAIL PROTECTED]> wrote: > Bill Janssen wrote: > > Greg Ewing writes: > >> If the standard format were designed so as to be > >> unambiguously distinguishable from all native > >> formats, ... > > > > All native formats both past and future. > > That's not difficult. > > I use 'posix' paths as my universal format. I convert them to native > paths just before writing them out or passing to a subsystem that > requires native paths.
Not a valid option. C:\Data\a_file.txt is a perfectly valid posix format filename. It's a file in the current directory (with some very strange characters in it). But it's also a native path in Windows. So how do you interpret it? And yes, I have seen precisely this problem occur with an application which took (posix) paths for use on a Unix server, but in a Windows client GUI. So we ended up with some really funky filenames on Unix to sort out :-( I stand by my assertion, it's a human problem, not a technical one. > What this means is that universal paths need never be serialized - they > are always converted to native form before being written anywhere. Again, I don't believe this is possible for all corner cases: what is the drive for /my/file on a Windows system? I'm not at all sure what you're trying to achieve here - if I'm running a program on a Windows system, I want to see Windows native paths for all external information (whether it's input from command line args or ini files, or output in messages etc). If I'm running that program on a Posix system, I want to see and use Posix files. If I want to write an ini file for the program which contains filenames, and which can be used unchanged on a Windows and a Posix system, I assert that I'm misguided (because I can't do it - drive letters will kill me as /data/xxx (or \data\xxx if you prefer) is ambiguous on Windows. If you mandate that all filenames must be relative, you could manage, but enforcing that is probably harder than just using native format everywhere and giving up on portable ini files... (I think this has strayed so far off topic as to be meaningless, so I'll leave it at that, and avoid perpetuating the thread...). Paul. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
