Pascal Chambon wrote:
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
<chambon.pas...@gmail.com <mailto:chambon.pas...@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. :-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
