[New-bugs-announce] [issue6939] shadows around the io truncate() semantics

Pascal Chambon report at bugs.python.org
Fri Sep 18 15:21:53 CEST 2009


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

I'm having trouble around the behaviour of the io module's truncate
methods, in py3k. If I remember well, under unix and older versions of
Python (with other file types), truncate never move the fiel pointer
(and had to fake that behaviour under windows as well, by
saving/restoring the file pointer).

However, I see nothing in the documentation of the io module about that,
and studying the _fileio.c code, it seems that now the file pointer is
(under all OS) moved to the truncation point, and left there.

Maybe it requires discusions on the mailing list, but personally I think
that the common unix behaviour (letting the file pointer untouched)
would be better for everyone, and that the doc should claim it.

Also, additional notes about the behaviour of that truncation (reminding
people that on some OS, the padding is zero-filled, on others it's
not...) would be great.

Current doc of io in py3k :
http://docs.python.org/py3k/library/io.html#io.IOBase.truncate
truncate(size=None)
    Truncate the file to at most size bytes. size defaults to the
current file position, as returned by tell().

Cheers
Pascal

----------
components: IO
messages: 92822
nosy: pakal
severity: normal
status: open
title: shadows around the io truncate() semantics
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________


More information about the New-bugs-announce mailing list