[Python-Dev] Re: tarfile

[Gustavo Niemeyer]

Hi Lars!

> > Itamar told me about some changes he submitted to zipfile, and weren't
> > accepted by lack of documentation and unittests. Here is an excerpt of
> > his message:
> [...]
> > Could you please review it!?
> 
> I had a look at it and IMO it's the right way. Too bad that the patch
> did not succeed. I started to include a similar method today replacing
> the readstr() method. The same will follow with writestr().

Thanks!

> But OTOH this does not solve the problem I described in my last message:
> >> [...]
> >> When using tarfile the user assumes that all of
> >> the meta-informations of a file like mode, ownership, modification
> >> time etc. are extracted as well, for example when restoring a backup.
>
> We should find a solution to that, most of the code of tarfile deals
> with these particular tasks...

What do you think about keeping the current zipfile semantics of
read/write returning strings, and using your suggesion of extract() and
add() to implement the new functionality of dumping to disk? We could
even have some kind of Dumper class, which would be responsible for
that task, and could be replaced by the user if necessary (personaly,
I'm not against something like "read = extractstr" as well).

> > I understand your position, and agree with you. Nevertheless, we should
> > let the interface as close as *possible*. If zipfile is not well
> > designed, I'd like to change it as well.
> >From my (insignificant) point of view, I would not care too much about
> standardization in this particular case, because the "standard"
> introduced by the zipfile module is *very* *very* limited.

Yes, zipfile.py interface's is not a nice example for a global interface
for file storing.

> I think we don't do ourselves a favour if we take zipfile's interface
> as a basis. And I think we don't do the user a favour because he would
> always tend towards mixing up both interfaces, which would both be
> somehow similar but OTOH fundamentally different.
>
> Wouldn't it be good to do it the opposite way round and create a solid
> interface for tarfile, which could be used as a basis for a
> new/patched zipfile or perhaps some day for other archiver-related
> modules?

Yes, it'd be nice indeed, but I wouldn't like to see, for example, a cpio
handler with a different interface in the future, because the current
ones don't fit well for the task. You told me you were willing to write
a PEP. Is that PEP about tarfile specific issues, or a general interface
for that kind of job?

> I mention again the small TarFileCompat class I wrote within 5
> minutes, which perfectly emulates a ZipFile class. Try that
> the other way 'round and you're sold down the river...

I understand..

> I apologize deeply for my obstinacy.... But I can't help myself.
> Please tell me, if I exaggerate or if I am wrong. But at the moment I
> don't have any idea how to be "as close as possible" to zipfile,
> sorry.

Again, you've done a great job with tarfile so far, and I'm thankful
for that. I'm sure we can handle those issues and still have something
you're proud of.

Btw, I've notice TarInfo is using class attributes on initialization.
Wouldn't instance attributes reflect better their meaning?

Thanks!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]