Lars Gustäbel added the comment:
I had the following idea: What about a separate class, let's call it
TarVolumeSet for now, that maps a set of (virtual) volumes onto one big
file-like object. This TarVolumeSet will be passed to a TarFile constructor as
the fileobj argument. It is subclassable for implementing custom behavior.
class MyTarVolumeSet(tarfile.TarVolumeSet):
def __init__(self, template):
self.template = template
def open_volume(self, volume_number):
return open(self.template % volume_number, "rb")
volumes = MyTarVolumesSet("test.tar.%03d")
with tarfile.open(fileobj=volumes, mode="r:") as tar:
for t in tar:
print(t.name)
In my opinion, this approach has a number of advantages: Most importantly, it
separates the multi-volume code from the TarFile class, which reduces the
invasiveness, complexity and maintenance burden of the original approach. The
TarFile class would be totally agnostic about the concept of multiple volumes,
TarVolumeSet looks just like another file-object to TarFile. Looks like the
cleanest solution to me so far.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18321>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
