Re: [Python-Dev] PEP 355 status
On Oct 25, 2006, at 10:48 PM, 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. > > Its been a while since I used classic MacOS - how do you handle things > like configuration files with path names in them? You aren't supposed to use paths at all. You're supposed to use an Alias whenever you're doing long term storage of a reference to a file. This allows the user to move the file around on the disk without breaking the reference, which is nice. The alias is an opaque datastructure which contains a bunch of redundant information used to locate the file. In particular, both pathname and (volumeId, dirId, name), as well as some other stuff like file size, etc. to help do fuzzy matching if the original file can't be found via the obvious locators. And for files on a file server, it also contains information on how to reconnect to the server if necessary. Much of the alias infrastructure carries over into OSX, although the strictures against using paths have been somewhat watered down. At least in OSX, you don't have the issue of the user renaming the boot volume and thus breaking every path someone ill-advisedly stored (since volume name was part of the path). For an example of aliases in OSX, open a file in TextEdit, see that it gets into the "recent items" menu. Now, move it somewhere else and rename it, and notice that it's still accessible from the menu. Seperately, try deleting the file and renaming another to the same name. Notice that it also succeeds in referencing this new file. Hm, how's this related to python? I'm not quite sure. :) James ___ 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
Re: [Python-Dev] PEP 355 status
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.
> # 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?
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
Re: [Python-Dev] PEP 355 status
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
_
Re: [Python-Dev] PEP 355 status
Talin wrote: > It seems that any Python program that manipulated paths > would have to be radically different in the environment that you describe. I can sympathise with that. The problem is really inherent in the nature of the platforms -- it's just not possible to do everything in a native classic MacOS way and be cross-platform at the same time. There has to be a compromise somewhere. With classic MacOS the compromise was usually to use pathnames and to heck with the consequences. You could get away with it most of the time. > 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. Yes, that's true. Calling it a "path" would be something of a historical misnomer. > 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. Yes, I thought of that, too. That's what you would have to do under the current scheme if you ever encountered a platform which truly had no textual representation of file locations. But realistically, it seems unlikely that such a platform will be invented in the foreseeable future (even classic MacOS *had* a notion of paths, even if it wasn't the preferred representation). So all this is probably YAGNI. -- 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 434 open ( +3) / 3430 closed ( +5) / 3864 total ( +8)
Bugs: 929 open (+13) / 6285 closed (+12) / 7214 total (+25)
RFE : 245 open ( +1) / 240 closed ( +0) / 485 total ( +1)
New / Reopened Patches
__
various datetime methods fail in restricted mode (2006-10-17)
http://python.org/sf/1578643 opened by lplatypus
PyErr_Format corrections (2006-10-17)
http://python.org/sf/1578999 opened by Martin v. Löwis
posix.readlink doesn't use filesystemencoding (2006-10-19)
http://python.org/sf/1580674 opened by Ronald Oussoren
Duplicated declaration of PyCallable_Check (2006-10-20)
CLOSED http://python.org/sf/1580872 opened by Matthias Klose
Allow textwrap to preserve leading and trailing whitespace (2006-10-20)
http://python.org/sf/1581073 opened by Dwayne Bailey
tarfile.py: 100-char filenames are truncated (2006-10-24)
CLOSED http://python.org/sf/1583506 opened by Lars Gustäbel
tarfile.py: better use of TarInfo objects with longnames (2006-10-24)
http://python.org/sf/1583880 opened by Lars Gustäbel
Tix: subwidget names (bug #1472877) (2006-10-25)
http://python.org/sf/1584712 opened by Matthias Kievernagel
Patches Closed
__
patch for building trunk with VC6 (2006-03-24)
http://python.org/sf/1457736 closed by loewis
a faster Modulefinder (2005-11-11)
http://python.org/sf/1353872 closed by theller
Duplicated declaration of PyCallable_Check (2006-10-20)
http://python.org/sf/1580872 closed by loewis
Exec stacks in python 2.5 (2006-09-18)
http://python.org/sf/1560695 closed by loewis
tarfile.py: 100-char filenames are truncated (2006-10-24)
http://python.org/sf/1583506 closed by gbrandl
New / Reopened Bugs
___
2.4.4c1 will not build when cross compiling (2006-10-16)
CLOSED http://python.org/sf/1578513 opened by smithj
--disable-sunaudiodev --disable-tk does not work (2006-10-17)
http://python.org/sf/1579029 opened by ThurnerRupert
Segfault provoked by generators and exceptions (2006-10-17)
http://python.org/sf/1579370 opened by Mike Klaas
Use flush() before os.exevp() (2006-10-18)
http://python.org/sf/1579477 opened by Thomas Guettler
Wrong syntax for PyDateTime_IMPORT in documentation (2006-10-18)
CLOSED http://python.org/sf/1579796 opened by David Faure
not configured for tk (2006-10-18)
http://python.org/sf/1579931 opened by Carl Wenrich
glob.glob("c:\\[ ]\*) doesn't work (2006-10-19)
http://python.org/sf/1580472 opened by Koblaid
"make install" for Python 2.4.4 not working properly (2006-10-19)
http://python.org/sf/1580563 opened by Andreas Jung
Configure script does not work for RHEL 4 x86_64 (2006-10-19)
http://python.org/sf/1580726 reopened by gbrandl
Configure script does not work for RHEL 4 x86_64 (2006-10-19)
http://python.org/sf/1580726 reopened by spotvt01
Configure script does not work for RHEL 4 x86_64 (2006-10-19)
http://python.org/sf/1580726 opened by Chris
httplib hangs reading too much data (2006-10-19)
http://python.org/sf/1580738 opened by Dustin J. Mitchell
Definition of a "character" is wrong (2006-10-20)
http://python.org/sf/1581182 opened by Adam Olsen
pickle protocol 2 failure on int subclass (2006-10-20)
http://python.org/sf/1581183 opened by Anders J. Munch
missing __enter__ + __getattr__ forwarding (2006-10-21)
http://python.org/sf/1581357 opened by Hirokazu Yamamoto
Text search gives bad count if called from variable trace (2006-10-20)
http://python.org/sf/1581476 opened by Russell Owen
test_sqlite fails on OSX G5 arch if test_ctypes is run (2006-10-21)
http://python.org/sf/1581906 opened by Skip Montanaro
email.header decode within word (2006-10-22)
http://python.org/sf/1582282 opened by Tokio Kikuchi
Python is dumping core after the test test_ctypes (2006-10-23)
http://python.org/sf/1582742 opened by shashi
Bulding source with VC6 fails due to missing files (2006-10-23)
CLOSED http://python.org/sf/1582856 opened by Ulrich Hockenbrink
class member inconsistancies (2006-10-23)
CLOSED http://python.org/sf/1583060 opened by EricDaigno
Different behavior when stepping through code w/ pdb (2006-10-24)
http://python.org/sf/1583276 opened by John Ehresman
tarfile incorrectly handles long filenames (2006-10-24)
CLOSED http://python.org/sf/1583537 opened by Mike Looijmans
yield+break stops tracing (2006-10-24)
http://python.org/sf/1583862 opened by Lukas Lalinsky
__str__ cannot be overridden on unicode-derived classes (2006-10-24)
http://python.org/sf/1583863 opened by Mike K
SSL "issuer" and "server" functions problems - security (2006-10-24)
http://python.org/sf/1583946 opened by John Nagle
remove() during ite
