RetroSearch Browse

Fri Sep 18 22:08:23 CEST 2009 · http://mail.python.org/pipermail/python-dev/2009-September/091896.html

On Sep 18, 2009, at 3:55 PM, MRAB wrote:

> I think that this should be an invariant:
>
>    0 <= file pointer <= file size
>
> so the file pointer might sometimes have to be moved.

> As for the question of whether 'truncate' should be able to lengthen a
> file, the method name suggests no; if the method name were 'resize',  
> for
> example, then maybe yes, zeroing the new bytes for security.

Why are you just making things up? There is a *vast* amount of  
precedent for how file operations should work. Python should follow  
that precedent and do like POSIX unless there's a compelling reason  
not to. Quoting:

        If  fildes  refers  to  a  regular  file,  the ftruncate()  
function shall cause the size of the file to be truncated to
        length. If the size of the file previously exceeded length,  
the extra data shall no longer be available to reads on the
        file.  If  the  file  previously  was smaller than this size,  
ftruncate() shall either increase the size of the file or
        fail.   XSI-conformant systems shall increase the size of the  
file.  If the file size is increased, the  extended  area
        shall appear as if it were zero-filled. The value of the seek  
pointer shall not be modified by a call to ftruncate().

James

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-September/091896.html below:

[Python-Dev] Fuzziness in io module specs