Roundup Robot added the comment:
New changeset 62723172412c by Antoine Pitrou in branch 'default':
Issue #23529: Limit the size of decompressed data when reading from
https://hg.python.org/cpython/rev/62723172412c
--
nosy: +python-dev
___
Python
Antoine Pitrou added the comment:
Thank you very much for being so perseverant! The patch is now pushed into the
default branch.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
Martin Panter added the comment:
Patch v9:
* Incorporated _PaddedFile.rewind() into seek() for simplicity
* Reverted to support fast-forwarding in non-seekable streams again
* Factored common checks into _check_can_seek()
* Documented “mtime” attribute and implemented it as a read-only
Martin Panter added the comment:
Yes my patch should be ready, unless we want to work on factoring more common
logic out of the gzip read() method.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
Antoine Pitrou added the comment:
Is it still work-in-progress or are you looking for a review?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
___
Nikolaus Rath added the comment:
I believe Martin's patch (v8) is ready for a core committer review. At least I
can't find anything to criticize anymore :-).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
Martin Panter added the comment:
Another behaviour change in v7 is the seekable() return value is now inherited
from underlying file, instead of always being True. I mentioned on Reitveld why
this could be a bad idea, but as it is undocumented and untested and will leave
the new behaviour
Nikolaus Rath added the comment:
Except for the pointless 'myfileobj' stuff in gzip.py, rev 8 of the patch looks
good to me.
(Btw, I'm not actually in favor of e.g. the seekable() change. The previous
patch was intended as a proof-of-concept to see what would be necessary to
inherit more
Nikolaus Rath added the comment:
As discussed in Rietveld, here's an attempt to reuse more DecompressReader for
GzipFile. There is still an unexplained test failure (test_read_truncated).
--
Added file: http://bugs.python.org/file38674/LZMAFile-etc.v7.patch
Martin Panter added the comment:
Wolfgang: If the patch here is too massive, perhaps you might like to review my
patch at Issue 23528 first. :) It only fixes the “gzip” module, but is
definitely simpler, so might have more chance of making it into 3.4 or 3.5 on
time.
===
Changes introduced
Martin Panter added the comment:
I am posting v6, which basically drops the buffer_size parameters. The change
is also pushed as a series of revisions to a Bit Bucket repository, see
https://bitbucket.org/vadmium/cpython/branches/compare/compression%0D@. I
thought that might help eliminate
Martin Panter added the comment:
Wolfgang: Unfortunately, I think that block of changes is largely unavoidable.
The write() method should not have changed in reality, but all the init and
read methods around it have been split into two classes, and the diff has
decided to compare the old
Wolfgang Maier added the comment:
The patch has a huge block replacement in the gzip.py module starting at
GzipFile.write, which makes it large and hard to identify changes. Could that
be ameliorated or is it too much work right now?
--
nosy: +wolma
Nikolaus Rath added the comment:
If you want to add support for buffer_size=0 in a separate patch/issue I think
that's fine. But in that case I would not add a buffer_size parameter now at
all. IMO, not having it is better as having it but not supporting zero (even if
it's documented that's
Martin Panter added the comment:
Posting LZMAFile-etc.v5.patch with the following changes:
* Merged with current code
* Changed BZ2File(buffer_size=...) to a keyword-only parameter and restored
previous unused “buffering” parameter. Also changed the LZMAFile parameter to
keyword-only for
Martin Panter added the comment:
Well my last patch just added the _compression.py file without doing anything
special, and it seems to be installed properly with “make install” so I will
assume nothing else needs to be done.
--
___
Python tracker
Nikolaus Rath added the comment:
On Mar 06 2015, Martin Panter rep...@bugs.python.org wrote:
Still to do: Need to find a better home for the _DecompressReader and
_BaseStream classes. Currently it lives in “lzma”, but apparently it
is possible for any of the gzip, bz2, lzma modules to not be
Martin Panter added the comment:
I am posting LZMAFile-etc.v3.patch, where I have implemented a “buffer_size”
parameter to the buffered LZMAFile etc classes. I have not implemented
open(buffering=...) for the time being (which should probably delegate to the
buffer_size parameter or return a
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
___
Nikolaus Rath added the comment:
On Feb 27 2015, Martin Panter rep...@bugs.python.org wrote:
In the code review, Nikolaus raised the idea of allowing a custom
“buffer_size” parameter for the BufferedReader. I think this would
need a bit of consideration about how it should work:
1. Should
Antoine Pitrou added the comment:
LZMAFile now uses BufferedReader.peek(). The current implementation seems
appropriate, but I am not comfortable with the current specification in the
documentation, which says it is allowed to not return any useful data.
What do you mean with useful data?
Martin Panter added the comment:
## BufferedReader.peek() ##
See https://bugs.python.org/issue5811#msg233750, but basically my concern is
that the documentation says “the number of bytes returned may be less or more
than requested”, without any mention of EOF or other conditions.
## Buffer
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
___
___
Python-bugs-list mailing
New submission from Martin Panter:
This is a follow-on from Issue 15955, which has added low-level support for
limiting the amount of data from the LZMA and bzip decompressors. The
high-level LZMAFile and BZ2File reader APIs need to make use of the new low
level max_length parameter.
I am
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
___
___
25 matches
Mail list logo
