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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4