[issue18430] gzip, bz2, lzma: peek advances file position of existing file object

[Nick Bargnesi]

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. The exact
    number of bytes returned is unspecified (the *size* argument is ignored).

    Although calling a :class:`LZMAFile` object's :meth:`peek` method does not
    advance its file position, the file position of the underlying
    :term:`file object` may be affected.

The point about mentioning "save and restore" notwithstanding, *any* documentation about the effect on position change is a step in the right direction. If the file position not changing is the better scenario, having the side effect documented is at least good. We can save people's time by being explicit about the side effect _and_ maintain code readability.

Imagine hunting for a bug manifesting itself as a change in file position only to find out a peek() call was the cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18430>
_______________________________________