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


Groups > comp.lang.python > #75369

Re: one to many (passing variables)

Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <antoon.pardon@rece.vub.ac.be>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.015
X-Spam-Evidence '*H*': 0.97; '*S*': 0.00; 'value,': 0.04; 'received:134': 0.05; 'none:': 0.07; 'returned.': 0.07; 'escape': 0.09; 'indicates': 0.09; "wouldn't": 0.14; 'better:': 0.16; 'block:': 0.16; 'expects': 0.16; 'mode,': 0.16; 'non-blocking': 0.16; 'or.': 0.16; 'returned,': 0.16; 'wrote:': 0.18; 'header :User-Agent:1': 0.23; 'bytes': 0.24; 'file.': 0.24; 'header:In- Reply-To:1': 0.27; 'testing': 0.29; 'mode': 0.30; 'code': 0.31; 'says': 0.33; 'skip:d 20': 0.34; 'could': 0.34; 'subject: (': 0.35; "can't": 0.35; 'something': 0.35; 'test': 0.35; 'but': 0.35; 'consistent': 0.36; 'subject:one': 0.36; 'done': 0.36; 'too': 0.37; 'problems': 0.38; 'follows:': 0.38; 'needed': 0.38; 'to:addr :python-list': 0.38; 'to:addr:python.org': 0.39; 'how': 0.40; 'around.': 0.60; 'reaching': 0.61; 'more': 0.64; 'taking': 0.65; 'close': 0.67; 'receive': 0.70; 'different.': 0.84; 'otten': 0.84; 'pardon': 0.84; 'prone': 0.91
X-IronPort-Anti-Spam-Filtered true
X-IronPort-Anti-Spam-Result AqIEAPLf2FOGuA9G/2dsb2JhbABZhy/Mc4McAYEnhHoBAQQBI1UGCwsYAgIFFgsCAgkDAgECAUUTCAKINgioOZE1hjIXgSyOJxaCY4FRAQSbZIcGjU2DSw
Date Wed, 30 Jul 2014 14:09:51 +0200
From Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version 1.0
To python-list@python.org
Subject Re: one to many (passing variables)
References <CAHXoDSB+-Vkggfd57nb9eLSK7Pb_fbuycGTJZM=+6=4VZo3F0w@mail.gmail.com> <8561innkmw.fsf@benfinney.id.au> <53D308CB.8030900@cdreimer.com> <lr68a2$i6d$1@ger.gmane.org> <53D8D693.9040505@rece.vub.ac.be> <lraldm$79v$1@ger.gmane.org>
In-Reply-To <lraldm$79v$1@ger.gmane.org>
Content-Type text/plain; charset=UTF-8
Content-Transfer-Encoding 7bit
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.12431.1406722193.18130.python-list@python.org> (permalink)
Lines 51
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1406722193 news.xs4all.nl 2923 [2001:888:2000:d::a6]:58262
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:75369

Show key headers only | 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