Roundup Robot added the comment:
New changeset 5ca6e8af0aab by Nadeem Vawda in branch '3.3':
#18430: Document that peek() may change the position of the underlying file for
http://hg.python.org/cpython/rev/5ca6e8af0aab
New changeset 0f587fe304be by Nadeem Vawda in branch 'default':
Closes
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18430
___
___
R. David Murray added the comment:
I don't think the comment about save and restore of the file position adds
enough value to be worth the possible confusion (do I only need to save and
restore around peek? Why?) I think the sentence should read, ex, Calling a
:class:`LZMAFile` object's
Serhiy Storchaka added the comment:
A file can be non-seekable (pipe, socket) and we can't unread unused data
back.
We can't implement GzipFile.peek() in terms of underlied file's peek() because
peek() doesn't guaranteed return more than one byte, but it should return at
least one byte if
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.
R. David Murray added the comment:
I chose 'access position' because that's the terminology used in the 'seek' man
page. 'file position' sounds odd to me, but since that is the term already
used it does make sense to be consistent.
--
assignee: - docs@python
components:
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 --
Serhiy Storchaka added the comment:
I guess this issue can't be fixed.
--
nosy: +nadeem.vawda, serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18430
___
Madison May added the comment:
Why would something like the following work?
#At the beginning of peek()
#keep track of prior offset
position = self.fileobj.tell()
#immediately before return statement
#restore previous fileobj offset
self.fileobj.seek(position)
--
nosy: +madison.may
Madison May added the comment:
*wouldn't
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18430
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Regardless of whether or not it *can* be fixed, I personally would not expect
the file position to be either unchanged or predictable. The file object is
being passed to something that is going to read and/or write from it, after
all. If the calling
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 it.
--
R. David Murray added the comment:
Hmm, yes. Perhaps it should say does not advance the gzip read position?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18430
___
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
Madison May added the comment:
Sounds good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18430
___
___
Python-bugs-list mailing list
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
16 matches
Mail list logo
