R. David Murray rdmur...@bitdance.com added the comment:
I agree with Amaury. IMO the IOError is the correct error, since it is
bubbling up unexpectedly (from zipfile's viewpoint) from a lower layer and is
not an error specific to the zip protocol implementation. (CF the discussion
New submission from Sridhar Ratnakumar sridh...@activestate.com:
When extracting a zip file containing deep hierarchy files, `extractall` throws
IOError on Windows - perhaps due to limitation in Windows max path length.
Ideally it should be throwing an instance of zipfile.ZipError - so that
Sridhar Ratnakumar sridh...@activestate.com added the comment:
It appears that there is no base class (zipfile.ZipError) for zipfile errors.
Maybe there should be? At the moment, I do:
try:
[...]
except zipfile.BadZipFile, zipfile.LargeZipFile:
[...]
.. which is of course unreliable.
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
How would you implement this? And would you turn a disk full error, for
example, into a ZipError as well?
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
Changes by Éric Araujo mer...@netwok.org:
--
versions: +Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10447
___
Sridhar Ratnakumar sridh...@activestate.com added the comment:
How would you implement this? And would you turn a disk full error, for
example, into a ZipError as well?
I see your point. I am not sure what a reliable way to do this would be. For
the record, this is how I workaround it:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I think you did the right thing already. The choice of which errors to catch
and which ones to let throw really depends on the usage
(what about permission or lock errors? other limitations due to a USB stick?
why is disk full
