Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75369

Re: one to many (passing variables)

Show all headers | View raw

On 30-07-14 13:37, Peter Otten wrote:

> Antoon Pardon wrote:
>
>> Taking this in consideration I think the io.RawIOBase.read got it
>> backwards.
>>
>> The documentation says the following:
>>
>> | If 0 bytes are returned, and size was not 0, this indicates end of file.
>> | If the object is in non-blocking mode and no bytes are available, None
>> | is returned.
>>
>> But typically if you are reading in non-blocking mode, no bytes availabe
>> can be treated as if you receive an empty (byte)string. While reaching the
>> end of the stream is different. So it would have been more consistent if
>> an empty (byte)string was return in case of no bytes availabe and None or
>> io.EOF or something like that in case of end of file.
>>
>> Now I have to write things as follows:
>>
>> for block in iter(partial(RawStream.read, 1024), ''):
>>     if block is not None:
>>         for b in block
>>             process(b)
> or
>
> for block in ...:
>     for b in block or ():
>         process(b)

No it obscures what is going on and is prone to problems if you have more code
that expects block to be a (byte)string. I think this is better:

for block in ...:
    block = block or ''
    for b in block:
        process(b)
    do_other_stuff_with(block) 

It is not that big a deal but you can't escape testing for an exceptional
value, whether you do it with an if or with an or. A test that wouldn't
be needed if they had done it the other way around. IMO they stayed too
close to how things are done in C. 

>> Otherwise I could write it more as follows:
>>
>> for block in iter(partial(RawStream.read, 1024), io.EOF):
>>     for b in block
>>         process(b)
>  

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: one to many (passing variables) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-07-30 14:09 +0200

csiph-web