while c = f.read(1)
sybrenUSE at YOURthirdtower.com.imagination
Tue Aug 23 14:13:15 CEST 2005
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.
> 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.
> 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. 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 is None:
I don't see a problem here.
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
More information about the Python-list