New submission from Nick Bargnesi:
Using existing file objects as arguments to the open functions in the gzip,
bz2, and lzma libraries can cause the underlying fileobj position to get
changed - and not quite in ways one would expect.
Calling peek against the returned file objects
Nick Bargnesi added the comment:
In that the underlying file position is not deterministic when used like this,
I'm inclined to agree.
Though faced with documentation stating it does not advance the file
position, it certainly is less than explicit about
Nick Bargnesi added the comment:
That's an improvement.
Using wording similar to the constructor's:
Calling a GzipFile object’s peek() method does not advance its position, but
the fileobj may be affected. The caller may wish to save the fileobj position
prior to calling peek() and resetting
Nick Bargnesi added the comment:
Proposed documentation change to gzip, bz2, and lzma modules, in patch form.
--
keywords: +patch
Added file: http://bugs.python.org/file30896/issue18430.patch
___
Python tracker rep...@bugs.python.org
http
Nick Bargnesi added the comment:
I'd suggest sticking with file position instead of switching to access
position. E.g., the complete lzma wording would be:
Return buffered data without advancing the file position. At least
one byte of data will be returned, unless EOF has been reached
