On 11/2/06, Talin <[EMAIL PROTECTED]> wrote: > One way to solve this would be to define a platform-neutral path > representation that can be "rendered" into either os-specific *or* > application-specific formats. I could read a Perforce path string, > convert that into an abstract path, do some work on it, and then convert > it back to a Perforce path - or convert to a local filesystem path if I > choose. Basically we'd have importers and exporters (format converters) > for paths. On Win32, for example, we could have an "NT" importer for > standard NT-style paths; a "Cygwin" importer that was more relaxed about > a mixture of forward- and back-slashes; and so on. > > Of course, there would always be a "shortcut" for the local filesystem > format - i.e., if no conversion was specified, then the local host > format would be used as the default. > > How such importers and exporters would actually look syntactically, I am > not sure yet. I'm open to ideas...
This sounds like a use case for a directory-component path object. If it treats paths as sequences like ['usr', 'local', 'lib', 'python2.4'] and you had to input them that way too, it would be a platform-neutral format. You'd still need to specify absolute/relative path, and in some cases choose the root for an absolute path, which is why Noam's module uses a special "root object" for the first element. This weekend I plan to code up a MiniPath containing the pathname-manipulation features of PEP 355, a MediumPath subclass adding the filesystem-dependent methods that some ppl frown on, and a MaxiPath subclass with my favorite additional methods. I'm thinking of making the path module a class attribute, so that you can subclass any of these and use ntpath or macpath instead of your default if you want. I'll also try my hand at Glyph's "safe join" feature if I can get it to work right, but that will be an optional separate method: either a .child instance method or a class method (not sure which is better). -- Mike Orr <[EMAIL PROTECTED]> _______________________________________________ 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
