Scott Dial writes: > [EMAIL PROTECTED] wrote: > > Talin writes: > > > (one additional postscript - One thing I would be interested in is an > > > approach that unifies file paths and URLs so that there is a consistent > > > locator scheme for any resource, whether they be in a filesystem, on a > > > web server, or stored in a zip file.) > > > > +1
> It would make more sense to register protocol handlers to this magical > unification of resource manipulation. I don't think it's that magical, and it's not manipulation, it's location. The question is, register where and on what? For example on my Mac there are some PDFs I want to open in Preview and others in Acrobat. To the extent that I have some classes which are one or the other, I might want to register the handler to a wildcard path object. > But allow me to perform my first channeling of Guido.. YAGNI. True, but only because when I do need that kind of stuff I'm normally writing Emacs Lisp, not Python. We have a wide variety of functions for manipulating path strings, and they make exactly the distinction between path and inode/content that Talin does (where a path is being manipulated, the function has "filename" in its name, where a file or its metadata is being accessed, the function's name contains "file"). Nonetheless there are two or three places where programmers I respect have chosen to invent path classes to handle hairy special cases. These classes are very useful in those special cases. One place where this gets especially hairy is in the TRAMP package, which allows you to construct "remote paths" involving (for example) logging into host A by ssh, from there to host B by ssh, and finally a "relay download" of the content from host C to the local host by scp. The net effect is that you can specify the path in your "open file" dialog, and Emacs does the rest automatically; the only differences the user sees between that and a local file is the length of the path string and the time it takes to actually access the contents. Once you've done that, that process is embedded into Emacs's notion of the "current directory", so you can list the directory containing the resource, or access siblings, very conveniently. I don't expect to reproduce that functionality in Python personally, but such use cases do exist. Whether a general path class can be invented that doesn't accumulate cruft faster than use cases is another issue. _______________________________________________ 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
