[Python-Dev] Re: tarfile module (update) (original) (raw)

Gustavo Niemeyer niemeyer@conectiva.com
Wed, 27 Nov 2002 02:47:18 -0200

Hello again Lars!

There is a two-level public API to tarfile. The low-level API which is the TarFile class with its init(), and the high-level API which is the module-level open() function. [...]

Ok, but I still belive that the default constructor should be the most common used interface, just like most (all) of the standard library. Even the default open is now an alias for the 'file' type constructor. If you want to offer a low level access scheme (what is nice), you could just move the current init() function to some other name (init, whatever), and leave for those advanced users to subclass TarFile, and change its interface.

The low-level API has not changed since the first days of tarfile and is thought for those (possibly rare) users who know what's going on and want to do very special things with the class, inconveniently but as versatilely as possible.

I'm a little bit sceptic about how many advanced users are already using the lowlevel interface offered by TarFile. Right now, I don't think this should block us from doing an enhancement.

The high-level API is remaining backwards compatible since at least the last 4 months, although almost constantly features were added to it and the internals were turned upside down several times. The high-level API is there for all users who want a straight-forward API that offers common solutions. The fact that there are several classmethods now can IMO be ignored, as long as nothing has changed for the user - he still has the choice between the two APIs. If the TarFile.open constructor replaces the init constructor, the choice between the two is gone.

I don't have anything against classmethods. I just don't see a need for them in that case.

The TarFile.open constructor itself is actually no constructor. Depending on which compression it shall use or if it must figure out the compression by itself, it decides which constructor to use. This is IMO exactly one benefit that comes with classmethods - you can use several different constructors for the same class. I don't see this as a disadvantage, but rather as a nice example on what classmethods are good for. There are certainly other possible solutions for this task, but I think I chose a rather obvious one.

BTW, I think the most used interface is this: import tarfile tar = tarfile.open(...) One simply doesn't have to bother if tarfile.open is a function, a class or a classmethod.

I'm not sure, as "from tarfile import *" will probably be a common idiom as well, and tarfile.open can't be exported in that case, as discussed before.

Lars, as that's just my opinion, I'm forwarding that message to python-dev so that people there can give their opinions about this as well. Perhaps I'm just nit picking.

Thank you for discussing that.

-- Gustavo Niemeyer

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