[Python-Dev] PEP 355 status

[Talin]

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