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. For reading paths, it depends on whether the paths are already in universal (posix) style or native style. If they are native, I use one method for reading them, if they are universal I use a different method (Well, in the current code base that's not true - since os.path always handles paths in posix format as well as native format, even when running on non-posix systems. So I just pass everything to os.path and it just works.) What this means is that universal paths need never be serialized - they are always converted to native form before being written anywhere. Which in turn implies that the 'universal' path format can be an in-memory-only format. And as such, it can express its 'universalness' by additional object properties or object types, rather than via any kind of weird string encoding. Thus, a universal path is nothing more than a posix path, except with a different object type. Representing non-posix concepts such as drive letters is done simply by not interpreting them; Or in some cases, deferring any interpretation until the user specifically calls a function to split off that part. So if you have a path beginning with "C:", it doesn't try to interpret what that means until you ask it to via splitdrive(). (This is a good reason to have paths represented as strings instead of as a tuple, since you can't defer interpretation this way with pre-parsed paths.) -- Talin _______________________________________________ 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
