On 6/23/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > On 6/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 6/23/07, Alexandre Vassalotti <[EMAIL PROTECTED]> 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.
Great! > > 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
