I am creating a file editing system and would like to make a line based tell() function instead of a byte based one. This function would be used inside of a "with loop" with the open(file) call. This function is part of a class that has:
self.f = open(self.file, 'a+')
# self.file is a string that has the filename in it
The following is the original function (It also has a char setting if you wanted line and byte return):
def tell(self, char=False):
t, lc = self.f.tell(), 0
self.f.seek(0)
for line in self.f:
if t >= len(line):
t -= len(line)
lc += 1
else:
break
if char:
return lc, t
return lc
The problem I'm having with this is that this returns an OSError and it has to do with how the system is iterating over the file but I don't understand the issue. Thanks to anyone who can help.
I have an older version of Python 3, and I'm on Linux instead of a Mac, but I was able to recreate something very close to your error:
An IO error, not an OS error, but otherwise the same. Bizarrely enough, I couldn't cause it using your
open('a+', ...)
, but only when opening the file in read mode:open('r+', ...)
.Further muddling things is that the error comes from
_io.TextIOWrapper
, a class that appears to be defined in Python's_pyio.py
file... I stress "appears", because:The
TextIOWrapper
in that file has attributes like_telling
that I can't access on the whatever-it-is object calling itself_io.TextIOWrapper
.The
TextIOWrapper
class in_pyio.py
doesn't make any distinction between readable, writable, or random-access files. Either both should work, or both should raise the sameIOError
.Regardless, the
TextIOWrapper
class as described in the_pyio.py
file disables thetell
method while the iteration is in progress. This seems to be what you're running into (comments are mine):In your
tell
method, you almost alwaysbreak
out of the iteration before it reaches the end of the file, leaving_telling
disabled (False
):One other way to reset
_telling
is theflush
method, but it also failed if called while the iteration was in progress:The way around this, at least on my system, is to call
seek(0)
on theTextIOWrapper
, which restores everything to a known state (and successfully callsflush
in the bargain):If that's not the solution for your system, it might at least tell you where to start looking.
PS: You should consider always returning both the line number and the character offset. Functions that can return completely different types are hard to deal with --- it's a lot easier for the caller to just throw away the value her or she doesn't need.
I don't know if this was the original error but you can get the same error if you try to call f.tell() inside of a line-by-line iteration of a file like so:
which can be easily substituted by the following:
Just a quick workaround for this issue:
As you are iterating over the file from the beginning anyways, just keep track of where you are with a dedicated variable:
Now
file_pos
will always be, whatfile.tell()
would tell you. Note that this only works for ASCII files as tell and seek work with byte positions. Working on a line-basis it's easy though to convert strings from byte to unicode-strings.