[docs] [issue14013] tarfile should expose supported formats

[Éric Araujo]

Éric Araujo <merwok at netwok.org> added the comment:

Thanks for the quick reply.

> I think it is good style to let tarfile figure out which supported compression methods are
> available instead of shutil or the user.
Note that shutil will not be wholly transparent when I’m done with the refactoring, as it will be able to translate 'xztar', 'bztar' and 'gztar' to tarfile mode strings, but will need to have a special case to morph 'bztar' to 'bz2'.  It will be a small ugliness.

(There will also be ugliness in packaging: Even if I make it transparently supports all formats that shutil supports, I’ll need to have a bit of duplication because packaging has a preferred format by platform.  Well.)

> Following 3.3's crypt module, I think the name `methods' is superior to `formats' (maybe
> `compression_methods' is even better).
Note that crypt’s methods really are instances of something called Method.  hashlib has algorithms_guaranteed and algorithms_available since 3.2 and shutil uses get_archive_formats and get_unpack_formats.  I went for tarfile.compression_formats.

> Also, crypt's concept of a sorted list from stronger to weaker could also make sense here:
Sure.  In my first patch I put gz first as it should be universally available, and then put xz before bz2 as I think bz2 is quickly losing ground to xz (even GNU and Debian are switching to xz for their archives).  The attached patch follows your idea.

BTW I will gladly wait for commits related to the other bugs (misc bugs and misc doc edits) and refresh my patch then.

----------
Added file: http://bugs.python.org/file24573/add-tarfile.compression_formats.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14013>
_______________________________________