Greg Ewing wrote: > Talin wrote: > >> That's true of textual paths in general - i.e. even on unix, textual >> paths aren't guaranteed to be unique or exist. > > What I mean is that it's possible for two different > files to have the same pathname (since you can mount > two volumes with identical names at the same time, or > for a file to exist on disk yet not be accessible via > any pathname (because it would exceed 255 characters). > I'm not aware of any analogous situations in unix. > >> Its been a while since I used classic MacOS - how do you handle things >> like configuration files with path names in them? > > True native classic MacOS software generally doesn't > use pathnames. Things like textual config files are > really a foreign concept to it. If you wanted to store > config info, you'd probably store an alias, which > points at the moral equivalent of the files inode > number, and use a GUI for editing it. > > However all this is probably not very relevant now, > since as far as I know, classic MacOS is no longer > supported in current Python versions. I'm just > pointing out that the flexibility would be there > if any similarly offbeat platform needed to be > supported in the future.
I'm not sure that PEP 355 included any such support - IIRC, the path object was a subclass of string. That isn't, however, a defense against what you are saying - just because neither the current system or the proposed improvement support the kinds of file references you are speaking of, doesn't mean it shouldn't be done. However, this does kind of suck for a cross-platform scripting language like Python. It means that any cross-platform app which requires access to multiple data files that contain inter-file references essentially has to implement its own virtual file system. (Python module imports being a case in point.) One of the things that I really love about Python programming is that I can sit down and start hacking on a new project without first having to go through an agonizing political decision about what platforms I should support. It used to be that I would spend hours ruminating over things like "Well...if I want any market share at all, I really should implement this as Windows program...but on the other hand, I won't enjoy writing it nearly as much." Then comes along Python and removes all of that bothersome hacker-angst. Because of this, I am naturally disinclined to incorporate into my programs any concept which doesn't translate to other platforms. I don't mind writing some platform-specific code, as long as it doesn't take over my program. It seems that any Python program that manipulated paths would have to be radically different in the environment that you describe. How about this: In my ontology of path APIs given earlier, I would tend to put the MacOS file reference in the category of "file locator schemes other than paths". In other words, what you are describing isn't IMHO a path at all, but it is like a path in that it describes how to get to a file. (Its almost like an inode or dirent in some ways.) An alternative approach is to try and come up with an encoding scheme that allows you to represent all of that platform-specific semantics in a string. This leaves you with the unhappy choice of "inventing" a new path syntax for an old platform. however. >> # Or you can just use a format specifier for PEP 3101 string format: >> print "Path in local system format is {0}".format( entry ) >> print "Path in NT format is {0:NT}".format( entry ) >> print "Path in OS X format is {0:OSX}".format( entry ) > > I don't think that expressing one platform's pathnames > in the format of another is something you can do in > general, e.g. going from Windows to Unix, what do you > do with the drive letter? Yeah, probably not. See, I told you not to take it too seriously! But I do feel that its important to be able to manipulate posix-style path syntax on non-posix platfosm, given how many cross-platform applications there are that have a cross-platform path syntax. In my own work, I find that drive letters are never explicitly specified in config files. Any application such as a parser, template generator, or resource manager (in other words, any application whose data files are routinely checked in to the source control system or shared across a network) tend to 'see' only relative paths in their input files, and embedding absolute paths is considered an error on the user's part. Of course, those same apps *do* internally convert all those relative paths to absolute, so that they can be compared and resolved with respect to some common base. Then again, in my opinion, the only *really* absolute paths are fully-qualified URLs. So there. :) > You can only really do it if you have some sort of > network file system connection, and then you need > more information than just the path in order to do > the translation. > > -- > Greg _______________________________________________ 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