On 1/28/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > I dropped the Cc: of Python-3000, because I don't think this discussion > falls under that mailing list's charter. As I understand it, the > Python-3000 mailing list is for discussing the details of implementing > Python 3000. "Stuff I'd like to see in Python 3000" doesn't go there, it > goes to "Python-Ideas".
python-ideas didn't exist when this thread was started. :) I was just giving a status report on existing issues we'd discussed on python-3000. You're right that any future work in this area will probably involve python-ideas. I'm waiting for Unipath to get some use before re-raising the question of what direction we want the stdlib to go. I also support the other proposal to move some functions from os.path/shutil to os, which is being worked on. > One part of your message caught my eye: > > Passing an absolute foreign path is an error, because there's no sane way > to interpret "C:\\" on Posix or "/" on Windows. > There is in fact a very sane way to interpret "/" on Windows: the root > directory of the "current" drive. It's equivalent to "\". That's one way to do it, but whether Unipath should presume this is what the programmer wants is another issue. One can make an argument either way. I found it appealing to categorically refuse to translate absolute paths to a foreign system, and force the user to make the path relative and explicitly attach it to a new root (or subdirectory). "Explicit is better than implicit", as the Python mantra goes. If this turns out to be a hassle for programmers, we can always be more lenient later. > I guess it isn't > widely known, but nearly all Windows APIs are agnostic about whether you use > "\" or "/" as a directory separator. (The only exceptions I recall are the > common dialog open / save file functions.) I'm a Windows programmer, and I > frequently use "/". I've heard contradictory things about this. Some people say just use "/" and be happy; others say you get into trouble sometimes because it's not the Windows kernel that does this but the application or function, so some applications support it and some don't. In particular I've heard that "/" on the command line is handled by the application, which may impose the DOS semantics ("option flag") rather than "directory separator". > The fact that you don't understand this about how Windows paths work makes > me nervous about your path library. For instance, did you correctly support > local paths on explicit drives (e.g. "d:../foo")? I did use Windows regularly until 1998. I do remember drive-relative paths. My question is, do people seriously use them anymore? In a Python program? Specifying a drive-relative path or chdir'ing to it should work. The one thing Unipath does is consider it absolute: isabsolute() returns True, and .components() and .split_root() return "d:" as the root of the filesystem -- which it is. Joining the components produces the original path, which Windows should correctly interpret. So I don't see the harm as treating it as absolute in my model. Maybe it does create some hardship for Windows users, and maybe I'll have to consider. But drive-relative paths are really an intermediate level between absolute and relative, and the model has no place for the relative drive specification. E.g., Path("../foo").components() => ["", "..", "foo"] Path("C:\\foo").components() => ["C:\\", "foo"] Path("C:../foo").components() => ["C:", "..", "foo"] Strictly speaking, the last path is relative so the first element should be "". But that would leave no place for the "C:" specifier, which would either belongs at index 0.5 or in a special attribute. Accommodating either would require changing the entire model to accommodate an obscure Windows-only feature, even though the model works quite well otherwise. It may be that Unipath just isn't suitable for manipulating Windows drive-relative paths, and making it do so would would mess up Unipath too much. The former is for Windows users to decide; the latter is for me to decide based on their input. I have also dropped .drive, .unc, .splitdrive(), and .splitunc(). I think .split_root() is robust enough for what people want to do. But I may be wrong. If there's necessity for those methods/properties I'll add them, but I don't want to add a bunch of legacy methods that will rarely be called. -- Mike Orr <[EMAIL PROTECTED]> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com