They shouldn't, really, and I don't care too much about what happens
in that case. It may depend on whether the I/O device honors seeks
beyond EOF or not.
On 7/20/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> How this different from setting the position to the new size? What
> should happe
How this different from setting the position to the new size? What
should happen when someone call truncate() with an argument greater
than the current size? Should it do a seek, or nothing?
Thanks,
-- Alexandre
On 7/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Unless anyone cares, it sho
Unless anyone cares, it should imply a seek to the indicated position
if an argument was present.
On 7/18/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> So, any decision on the proposed semantic change of truncate?
>
> -- Alexandre
>
> On 7/3/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wro
So, any decision on the proposed semantic change of truncate?
-- Alexandre
On 7/3/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 7/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Honestly, I think truncate() should always set the current position to
> > the new size, even though t
On 03/07/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> I also find the semantic make more sense too. For example:
>
> >>> s = StringIO("Good bye, world")
> >>> s.truncate(10)
> >>> s.write("cruel world")
> >>> s.getvalue()
> ???
>
> I think that should return "Good bye, cruel worl
On 7/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Honestly, I think truncate() should always set the current position to
> the new size, even though that's not what it currently does.
Thought about that and I think that would be the best thing to do.
That would avoid making StringIO unneces
Honestly, I think truncate() should always set the current position to
the new size, even though that's not what it currently does. Or at
least it should set it to the new size if that's less than the current
position. What's the rationale (apart from "Unix defined it so") why
it currently leaves t
On 7/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Honestly, I think truncate() should always set the current position to
> the new size, even though that's not what it currently does. Or at
> least it should set it to the new size if that's less than the current
> position. What's the ration
If StringIO is not allowed to over-seek, what should happen to the
current file position when it is truncated?
>>> s = StringIO("Hello world!")
>>> s.seek(0, 2)
>>> s.truncate(2)
>>> s.tell()
???
Truncating can either set the position to the new string size, or it
leaves it alone.
Can someone, other than Guido, review my patch? He is in vacation
right now, so he probably won't have the time to review and submit it
until August.
Thanks,
-- Alexandre
On 6/25/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 6/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 6
On 6/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 6/23/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> I agree with this. I will try to write a patch to fix io.BytesIO.
Great!
I got the patch (it's attached to this email). The fix was simpler
than I thought.
I would like to wri
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
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 h
On 6/23/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 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 file
Hello,
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?
And one more thing, the close method on StringIO/BytesIO objects
doesn't work. I will try to fix that too.
15 matches
Mail list logo
