By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,035 Members | 1,995 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,035 IT Pros & Developers. It's quick & easy.

pep 3116 behaviour on non-blocking reads

P: n/a
In the RawIOBase class I read the following:

..read(n: int) -bytes

Read up to n bytes from the object and return them. Fewer than n
bytes may be returned if the operating system call returns fewer
than n bytes. If 0 bytes are returned, this indicates end of file.
If the object is in non-blocking mode and no bytes are available,
the call returns None.
I would like the developers to reconsider and return 0 bytes when no
bytes are available and let None indicate end of file.

The reason is that this can lead to clearer code that will work
independant of the blocking mode of the stream.

Consider a consumer that just has to treat each byte. Then with
the current choice the code will look something like the following
(assuming pep 315 is implemented)
| do:
| buf = stream.read(nr)
| while buf != "":
| if buf is not None:
| for b in buf:
| treat(b)
If what the method returns follows my proposal, the code to do the same
would look something like the following:
| do:
| buf = stream.read(nr)
| while buf is not None:
| for b in buff:
| treat(b)
The advantage with my propsal is that in a lot of cases an empty buffer
can be treated just the same as a non-empty one and that is reflected
in the return values of my proposal.
--
Antoon Pardon
Aug 9 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Antoon Pardon wrote:
I would like the developers to reconsider and return 0 bytes when no
bytes are available and let None indicate end of file.
That would be a major departure from the way IO has
always been handled before in Python, which follows
the Unix model.

Also, only code that deals with non-blocking streams
will ever get None, and such code is relatively rare,
so most code won't have to worry about the None case.

Even when dealing with a non-blocking stream, usually
there will be some other way (such as select) used to
determine when there is something to be read from a
stream, and it won't be read otherwise. In that case,
the code *still* won't ever see a None.

So I think the PEP has it right.

--
Greg
Aug 10 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.