On Jul 22, 12:45 am, Terry Reedy <tjre...@udel.edu> wrote: > On 7/22/2011 12:48 AM, rantingrick wrote: > > On Jul 21, 11:13 pm, Corey Richardson<kb1...@aim.com> wrote:
> Hmm. Archives are more like directories than files. Windows, at least, > seems to partly treat zipfiles as more or less as such. Yes but a zipfile is just a file not a directory. This is not the first time Microsoft has "mislead" people you know. ;-) > Certainly, 7zip > present a directory interface. So opening a zipfile/tarfile would be > like opening a directory, which we normally do not do. On the other > hand, I am not sure I like python's interface to directories that much. I don't think we should make comparisons between applications and API's. > It would be more sensible to open files within the archives. Certainly, > it would be nice to have the result act like file objects as much as > possible. Well you still need to start at the treetop (which is the zip/tar file) because lots of important information is exposed at that level: * compressed file listing * created, modified times * adding / deleting * etc. I'll admit you could think of it as a directory but i would not want to do that. People need to realize that tar and zip files are FILES and NOT folders. > Seaching open issues for 'tarfile' or 'zipfile' returns about 40 issues > each. So I think some people would care more about fixing bugs than > adjusting the interfaces. Of course, some of the issues may be about the > interface and increasing consistency where it can be done without > compatibility issues. Yes i agree! If we can at least do something as meager as this it would be a step forward. However i still believe the current API is broken beyond repair so we must introduce a new "archive" module. That's my opinion anyway. > However, I do not think there are any active > developers focued on those two modules. We need some fresh blood infused into Python-dev. I have been trying to get involved for a long time. We as a community need to realize that this community is NOT a homogeneous block. We need to be a little more accepting of new folks and new ideas. I know this language would evolve much quicker if we did. > > Unfortunately i know what the "powers that be" are going to say about > > fixing this wart. > > > PTB: "Sorry we cannot break backwards compatibility" > > Do you propose we break compatibility more than we do? You are not the > only Python ranter. People at Google march into Guido's office to > complain instead of posting here. Well, i do feel for Guido because i know he's taking holy hell over this whole Python 3000 thing. If you guys don't remember i was a strong opponent of almost all the changes a few years ago (search the archives). However soon after taking a "serious" look at the changes and considering the benefits i was convinced. I believe we are moving in the correct direction with the language HOWEVER the library is growing stale by the second. I want to breathe new life into this library and i believe many more people like myself exist but they don't know how to get involved. I can tell everyone who is listening the easiest first step is simply to speak up and make a voice for yourself. Don't be afraid to state your opinions. You can start right now by chiming in on this thread. Anybody is welcome to offer opinions no matter what experience level. > > Rick: But what about Python 3000? > > PTB: " Oh, well, umm, lets see. Well that was then and this is now! > > The changes made for 3.0 were more than enough for some people to > discourage migration to Py3. And we *have* made additional changes > since. So the resistance to incompatible feature changes has increased. Yes i do understand these changes have been very painful for some folks (me included). However there is only but one constant in this universe and that constant is change. I believe we can improve many of these API's starting with zip/tar modules. By the time Python 4000 gets here (and it will be much sooner than you guys realize!) we need to have this stdlib in pristine condition. That means: * Removing style guide violations. * Removing inconsistencies in existing API's. * Making sure doc strings and comments are everywhere. * Cleaning up the IDLE library (needs a complete re-write!) * Cleaning up Tkinter. * And more Baby steps are the key to winning this battle. We hit all the easy stuff first (doc-strings and style guide) and save the painful stuff for Python 4000. Meanwhile we introduce new modules and deprecate the old stuff. However we need to start the python 4000 migration now. We cannot keep putting off what should have already been done in Python 3000. > > Maybe i can offer a solution. A NEW module called "archive.py" (could > > even be a package!) which exports both the zip and tar file classes. > > However, unlike the current situation this archive module will be > > consistent with it's API. > > Not a bad idea. Put it on PyPI and see how much support you can get. Thanks, I might just do that! -- http://mail.python.org/mailman/listinfo/python-list
