RetroSearch Browse

Fri Sep 18 22:24:52 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-September/091898.html

James Y Knight wrote:
> 
> 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().
> 
"making things up"? I'm just expressing an opinion!

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

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

[Python-Dev] Fuzziness in io module specs