[Python-Dev] Fuzziness in io module specs - PEP update proposition

[MRAB]

Pascal Chambon wrote:
> Daniel Stutzbach a écrit :
>> On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon 
>> <chambon.pascal at gmail.com <mailto:chambon.pascal at gmail.com>> wrote:
>>
>>     *RawIOBase*.readinto(b: bytes) -> int
>>
>>
>> "bytes" are immutable.  The signature is:
>>
>> *RawIOBase*.readinto(b: bytearray) -> int
>>
>> Your efforts in working on clarifying these important corner cases is 
>> appreciated. :-)
>>
> You're welcome B-)
> 
> Indeed my copy/paste of the current pep was an epic fail - you'll all 
> have recognized readinto actually dealt with bytearrays, contrarily to 
> what the current pep tells
> -> http://www.python.org/dev/peps/pep-3116/
> 
> RawIOBase.read(int) takes a positive-or-zero integer indeed (I am used 
> to understanding this, as opposed to "strictly positive")
> 
> Does MRAb's suggestion of providing beginning and end offsets for the 
> bytearray meets people's expectations ? Personnaly, I feel readinto is a 
> very low-level method, mostly used by read() to get a result from 
> low-level native functions (fread, readfile), and read() always provides 
> a buffer with the proper size... are there cases in which these two 
> additional arguments would provide some real gain ?
> 
It's useful if you want to fill the buffer but 'read' might return fewer
bytes than you asked for because it returns only what's available. That
might not happen for files, but it might for other forms of I/O. Other
languages, like Delphi and Java, which read into pre-existing arrays,
have or allow the extra parameters.
> 
> Concerning the "backward compatibility" problem, I agree we should not 
> break specifications, but breaking impelmentation details is another 
> thing for me. It's a golden rule in programmers' world : thou shalt 
> NEVER rely on implementation details. Programs that count on these (eg. 
> thinking that listdir() will always returns "." and ".." as first 
> item0... until it doesnt anymore) encounter huge problems when changing 
> of platform or API version. When programming with the current 
> truncate(), I would always have moved the file pointer after truncating 
> the file, simply because I have no idea of what might happen to it 
> (nothing was documented on this at the moment, and looking at the 
> sources is really not a sustainable behaviour).
> So well, it's a pity if some early 3.1 users relied on it, but if we 
> stick to the current semantic we still have a real coherency problem - 
> seek() is not limited in range, and some experienced programmers might 
> be trapped by this non-conventionnal truncate() if they rely on posix or 
> previous python versions... I really dislike the idea that truncate() 
> might move my file offset even when there are no reasons for it.
> 
Well, if it's consistent and documented (and not totally stupid), I
can't really complain. :-)