[Python-3000] StringIO/BytesIO in io.py doesn't over-seek properly
Guido van Rossum
guido at python.org
Sat Jun 23 20:48:11 CEST 2007
On 6/23/07, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On 6/23/07, Guido van Rossum <guido at python.org> wrote:
> > On 6/23/07, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> > > I think found a bug in the implementation of StringIO/BytesIO in the
> > > new io module. I would like to fix it, but I am not sure what should
> > > be the correct behavior. Any hint on this?
> > BytesIO should behave the way Unix files work: just seeking only sets
> > the read/write position, but writing inserts null bytes between the
> > existing end of the file and the new write position. (Writing zero
> > bytes doesn't count; I've just experimentally verified this.)
> I agree with this. I will try to write a patch to fix io.BytesIO.
> > I think however that for StringIO this should not be allowed -- seek()
> > on StringIO is only allowed to accept cookies returned by tell() on
> > the same file object.
> I am not sure what you mean, by "cookies", here. So, do you mean
> StringIO would not be allowed to seek beyond the end-of-file?
tell() returns a number that doesn't necessary a byte offset. It's an
abstract value that only seek() knows what to do with.
TextIOBase in general doesn't support arbitrary seeks at all.
I just realize that a different implementation of StringIO could use
"code unit" offsets and then it could be allowed to seek beyond EOF.
But IMO it's not required to do that (and the current implementation
doesn't work that way -- it's a TextIOWrapper on top of a BytesIO).
> > > And one more thing, the close method on StringIO/BytesIO objects
> > > doesn't work. I will try to fix that too.
> > What do you want it to do? I'm thinking perhaps it doesn't need to do anything.
> Free the resources held by the object, and make all methods of the
> object raise a ValueError if they are used.
I'm not sure what the use case for that is (even though the 2.x
StringIO does this).
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000