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

[Gustavo Niemeyer]

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 ]