This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nbargnesi
Recipients madison.may, nadeem.vawda, nbargnesi, r.david.murray, serhiy.storchaka
Date 2013-07-13.02:15:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1373681733.63.0.144906347089.issue18430@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-07-13 02:15:33nbargnesisetrecipients: + nbargnesi, nadeem.vawda, r.david.murray, serhiy.storchaka, madison.may
2013-07-13 02:15:33nbargnesisetmessageid: <1373681733.63.0.144906347089.issue18430@psf.upfronthosting.co.za>
2013-07-13 02:15:33nbargnesilinkissue18430 messages
2013-07-13 02:15:33nbargnesicreate