|
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
Newsgroups: comp.lang.python
From: Chuck Rhode <CRh...@LacusVeris.com>
Date: Tue, 05 Jun 2007 13:48:30 -0500
Local: Wed, Jun 6 2007 4:48 am
Subject: Re: Python 3000: Standard API for archives?
Tim Golden wrote this on Mon, 04 Jun 2007 15:55:30 +0100. My reply is
below. > Chuck Rhode wrote: Yeah, this is in the daydreaming stages. I'd like to maintain >> samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +0000. My reply is >> below. >>> I think it would be a good thing if a standardized interface >>> existed, similar to PEP 247. This would make it easier for one >>> script to access multiple types of archives, such as RAR, 7-Zip, >>> ISO, etc. >> Gee, it would be great to be able to open an archive member for >> update I/O. This is kind of hard to do now. If it were possible, >> though, it would obscure the difference between file directories >> and archives, which would be kind of neat. Furthermore, you could >> navigate archives of archives (zips of tars and other >> abominations). > Just put something together a module called "archive" or whatever, > which exposes the kind of API you're thinking of, offering support > across zip, bz2 and whatever else you want. Put it up on the > Cheeseshop, announce it on c.l.py.ann and anywhere else which seems > apt. See if it gains traction. Take it from there. > NB This has the advantage that you can start small, say with zip and > bz2 support and maybe see if you get contributions for less common > formats, even via 3rd party libs. If you were to try to get it into > the stdlib it would need to be much more fully specified up front, I > suspect. not-just-read-only libraries of geographic shapefiles, which are available free from governmental agencies and which are riddled with obvious errors. Typically these are published in compressed archives within which every subdirectory is likewise compressed (apparently for no other purpose than a rather vain attempt at flattening the directory structure, which must be reconstituted on the User's end anyway). Building a comprehensive index to what member name(s) the different map layers (roads, political boundaries, watercourses) have in various political districts of varying geographic resolutions is much more than merely frustrating. I've given it up. However, I believe that once I've located something usable, the thing to do is save a grand unified reference locator (GURL) for it. The GURL would specify a directory path to the highest level archive followed by a (potential cascade of) archive member name(s for enclosed archives) of the data file(s) to be operated on. Unpacking and repacking would be behind the scenes. Updates (via FTP) of non-local resources would be transparent, too. I think, though, that notes about the publication date, publisher, resolution, area covered, and format of the map or map layer ought to be kept out of the GURL. My whole appetite for this sort of thing would vanish if access to the -- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||