Message192988
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. |
|
Date |
User |
Action |
Args |
2013-07-13 02:15:33 | nbargnesi | set | recipients:
+ nbargnesi, nadeem.vawda, r.david.murray, serhiy.storchaka, madison.may |
2013-07-13 02:15:33 | nbargnesi | set | messageid: <1373681733.63.0.144906347089.issue18430@psf.upfronthosting.co.za> |
2013-07-13 02:15:33 | nbargnesi | link | issue18430 messages |
2013-07-13 02:15:33 | nbargnesi | create | |
|