| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
(ZIP file spec. says in section K, "General notes" in point 1 that unless
specified otherwise values are unsigned and they are not specified as signed in
the spec).
Closes bug #679953. Thanks Jimmy Burgett.
|
| |
|
|
| |
OverflowError. Fix from Albert Chin
|
| |
|
|
|
|
|
|
|
| |
(Contributed by Steven Taschuk)
Replaces a bare except that caused all errors to be mis-reported as
archive errors.
Added a related NEWS item.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a patch for Bug 755031: If a null byte appears in
a file name, Python zipfile.py retains it, but InfoZip
terminates the name. Null bytes in file names are used
as a trick by viruses. I tested WinZip, and it also
truncates the file name at the null byte.
The patch also fixes a buglet: If a zipfile incorrectly
uses a directory separator other than '/', there was an
invalid complaint that the central directory name does
not match the file header name.
I also removed my name from the top of the file. It was
there for legal reasons which I believe no longer apply.
Many people have worked on this file besides me.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows ZipFile.writestr() to be called with
an archive file name instead of a ZipInfo instance:
z = ZipFile("myarchive.zip", "w")
z.writestr("foo/baz/file.ext", data)
z.close()
I found the old writestr() method very inconvenient
for simple (but common) things.
If called with a file name instead of a ZipInfo
instance, the date_time is set to the current date/time,
which makes sense to me for anonymous data.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x in string.whitespace => x.isspace()
type(x) in types.StringTypes => isinstance(x, basestring)
isinstance(x, types.StringTypes) => isinstance(x, basestring)
type(x) is types.StringType => isinstance(x, str)
type(x) == types.StringType => isinstance(x, str)
string.split(x, ...) => x.split(...)
string.join(x, y) => y.join(x)
string.zfill(x, ...) => x.zfill(...)
string.count(x, ...) => x.count(...)
hasattr(types, "UnicodeType") => try: unicode except NameError:
type(x) != types.TupleTuple => not isinstance(x, tuple)
isinstance(x, types.TupleType) => isinstance(x, tuple)
type(x) is types.IntType => isinstance(x, int)
Do not mention the string module in the rlcompleter docstring.
This partially applies SF patch http://www.python.org/sf/562373
(with basestring instead of string). (It excludes the changes to
unittest.py and does not change the os.stat stuff.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Big Hammer to implement -Qnew as PEP 238 says it should work (a global
option affecting all instances of "/").
pydebug.h, main.c, pythonrun.c: define a private _Py_QnewFlag flag, true
iff -Qnew is passed on the command line. This should go away (as the
comments say) when true division becomes The Rule. This is
deliberately not exposed to runtime inspection or modification: it's
a one-way one-shot switch to pretend you're using Python 3.
ceval.c: when _Py_QnewFlag is set, treat BINARY_DIVIDE as
BINARY_TRUE_DIVIDE.
test_{descr, generators, zipfile}.py: fiddle so these pass under
-Qnew too. This was just a matter of s!/!//! in test_generators and
test_zipfile. test_descr was trickier, as testbinop() is passed
assumptions that "/" is the same as calling a "__div__" method; put
a temporary hack there to call "__truediv__" instead when the method
name is "__div__" and 1/2 evaluates to 0.5.
Three standard tests still fail under -Qnew (on Windows; somebody
please try the Linux tests with -Qnew too! Linux runs a whole bunch
of tests Windows doesn't):
test_augassign
test_class
test_coercion
I can't stay awake longer to stare at this (be my guest). Offhand
cures weren't obvious, nor was it even obvious that cures are possible
without major hackery.
Question: when -Qnew is in effect, should calls to __div__ magically
change into calls to __truediv__? See "major hackery" at tail end of
last paragraph <wink>.
|
| |
|
|
|
|
| |
ZipFile.__del__(): call ZipFile.close(), like its docstring says it does.
ZipFile.close(): allow calling more than once (as all file-like objects
in Python should support).
|
| | |
|
| | |
|
| |
|
|
|
| |
Patch by Jim Ahlstrom which lets java's zipfile classes read zipfiles
create by zipfile.py.
|
| |
|
|
|
|
| |
the directory separator, as required by the format specification.
This closes SF bug #440693.
|
| | |
|
| |
|
|
|
|
| |
ZipFile.close() method that should be part of the preceding 'if'
block. On some platforms (Mark noticed this on FreeBSD 4.2) doing a
flush() on a file open for reading is not allowed.
|
| |
|
|
|
|
| |
This came out of SF bug #411881.
Note that there's another unqualified except: still.
|
| |
|
|
|
|
| |
This applies the patch Fred Drake created to fix it.
I'm checking it in since I had to apply the patch anyway in order
to test its behavior on Windows.
|
| | |
|
| |
|
|
|
| |
Add support to zipfile to support opening an archive represented by an
open file rather than a file name.
|
| |
|
|
| |
giving it a slight facelift
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
header and central directory structures, and use them as appropriate.
The point being to make it easier to tell what is getting pulled out
where; magic numbers are evil!
Change the computation of the ZipInfo.file_offset field to use the
length of the relevant "extra" field -- there are two different ones,
and the wrong one had been used. ;-(
This closes SF tracker patch #403276, but more verbosely than the
proposed patch.
|
| |
|
|
| |
there was an IOError opening the underlying file in ZipFile.__init__().
|
| | |
|
| |
|
|
|
|
|
|
| |
PyZipFile class.
End sentences in docstrings with periods.
Reformat docstrings to be more similar to those of other modules.
|
| |
|
|
|
|
| |
Error reported via email by Pete Shinners <pete@visionart.com>.
Fixed some indentation inconsistencies.
|
| |
|
|
| |
Thanks to Hubert Hoegl <hubert.hoegl@dlr.de> for finding this bug.
|
| |
|
