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.
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
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 30/06/2007 22.54, Matt Chisholm wrote:
> I've created and submitted a new PEP proposing support for labels in
> Python's break and continue statements. Georg Brandl has graciously
> added it to the PEP list as PEP 3136:
>
> http://www.python.org/dev/peps/pep-3136/
>
> I understand that the d
On 30/06/2007 22.54, Matt Chisholm wrote:
> I've created and submitted a new PEP proposing support for labels in
> Python's break and continue statements.
>
> http://www.python.org/dev/peps/pep-3136/
-1. Confusing nested loops are best broken out into
separate functions rather than patching over
