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

[Pascal Chambon]

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 ?


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.

Regards,
Pascal




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090920/2fd8b208/attachment-0001.htm>