while c = f.read(1)
apardon at forel.vub.ac.be
Tue Aug 23 14:47:17 CEST 2005
Op 2005-08-23, Sybren Stuvel schreef <sybrenUSE at YOURthirdtower.com.imagination>:
> Antoon Pardon enlightened us with:
>> The problem with interpreting empty as false is that empty just
>> means no data now. But no data now can mean no data yet or it can
>> mean no more data. The problem is not so much as having empty
>> interpreted as false but that people don't seem to think about which
>> false value would be more appropiate in particular circumstances.
> By no means can you take all possible future alterations in account.
> You have to make assumptions somewhere.
But having to write out a boolean expression fully, would force
one to make his assumptions explicite. My impression is that
people don't actually make assumptions but are happy to just
throw a variable in a conditional context. They only begin
to think about the assumptions this imply when things break.
>> IMO reading '' from network connection is the most natural result
>> when no data is ready and this should be treated differently from an
>> EOF which would indicate the connection was closed.
>> But how can you do this when somewhere else '' is used as an
>> indication for an EOF.
> That's called "a protocol". If another protocol is used than the
> software is written for, it'll break. This has nothing to do with
> accepting something as False or True.
Yes it has. That empty sequences are treated as false in a conditional
context, influences what kind of protocols are used.
>> And it is IMO this kind of comments that lead to '' being used as an
> And who cares if it is? In a blocking environment, it seems pretty
> okay to me.
Not all environments are blocking and it seems to be me it is better
to use protocols that are are as much as possible independant from
whether the environment is blocking or not.
> A read() call could block, waiting for more data to
> arrive. If there is none because the connection is down, for instance,
> it could return ''. Of course, raising an exception would be better in
> such a case, and it would also remove any ambiguity.
>> I have yet to see a mathematical work where 0, or any kind of empty
>> sequence is treated as false.
> In that case, properly define your variables to hold either booleans
> or numbers, and only test booleans in an "if var:" clause, and only
> test numbers in an "if var != 0:" clause.
>> a bytestring when data is available,
>> '' when no data is available
>> None when the connection was closed
> Seems pretty nice to me. In such a case, one could do:
> data = network.read()
> if data:
> if data is None:
> I don't see a problem here.
That is because you are looking at it too much in isolation.
What if you have a function that among things handles bytes
coming from a stream. Whether that stream is a regular file
or a network connection may be irrelevant for the function,
but if regular files return '' for EOF and other streams
don't, you are in trouble. And IMO that '' is treated as
false played its parts in deciding for it as indicating EOF.
More information about the Python-list