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