On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote: > I tried to make a separate PathAlgebra class and FSPath class, but it > got so unweildly to use I made the latter a subclass. They're now > called PathName and Path.
This makes sense to me. An FSPath without path algebra is basically a "directory listing" That might be a useful abstraction on its own, or it might be too much purity. > My idea, based on Noam's proposal, was to consider the root: > / > \ > c:\ > C: > \\unc_share\ > or "" for a relative path. That way, root + rest would always be > concatenation without a separator. But os.path.split* don't work like > this. [ They put the C: or such as the root, and the first \ in the path] > Do we even need p.drive and p.unc if we have > p.split_root() that handles all kinds of roots? I don't think so. Maybe on a WindowsFSPath subclass, for compatibility. But taking them out of the generic path is a good thing. Most people don't need to worry about them, and shouldn't need to wonder whether or not they do. > Noam distinguished between a drive-relative (r"C:foo") and > drive-absolute (r"C:\foo"). I'm treating the former as absolute > because I don't think it matters in this context. I think you are correct, though I'm not sure I would have thought of it. C: without a slash is effectively a mount point into the current directory. This particular mount point might shift around unexpectedly, but ... someone could rewrite the regular files on you too. It does make a leading ".." meaningful though; I'm not sure if that matters. > >>> ntpath.join(r"C:\ "[:-1], "foo") > 'C:\\foo' > (The latter funny syntax is to get around the fact that you can't have > a backslash at the end of a raw string literal.) You have to double it. One way to make lemonade of this lemon is to add a class attribute P.sep equivalent to os.path.sep. (And, realistically, the separator is more tied to the File System than it is to the Operating System.) If might encourage people to use path.sep instead of just assuming the locally correct character. -jJ _______________________________________________ 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
