while c = f.read(1)

[Antoon Pardon]

Op 2005-08-22, Steve Holden schreef <steve at holdenweb.com>:
> Antoon Pardon wrote:
>> Op 2005-08-19, Donn Cave schreef <donn at u.washington.edu>:
>> 
>>>In article <slrndgbole.209.apardon at rcpc42.vub.ac.be>,
>>> Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>...
>>>
>>>>But '', {}, [] and () are not nothing. They are empty containers.
>>>
>>>Oh come on, "empty" is all about nothing.
>> 
>> 
>> No it is not. There are situation where False or None should
>> be treated differently from an empty sequence.
>> 
>> Empty can mean, "nothing yet" which should be treated
>> differently from "nothomg more".
>> 
>> 
>>>>And 0 is not nothing either it is a number. Suppose I have
>>>>a variable that is either None if I'm not registered and a
>>>>registration number if I am. In this case 0 should be treated
>>>>as any other number.
>>>>
>>>>Such possibilities, make me shy away from just using 'nothing'
>>>>as false and writing out my conditionals more explicitly.
>>>
>>>Sure, if your function's type is "None | int", then certainly
>>>you must explicitly check for None.
>> 
>> 
>> The fact is that python doesn't know which type a function is.
>> So why does python guess that zero should be treated as false.
>> 
> Python doesn't guess. There are a range of values that will be treated, 
> in a Boolean context (how perlish) as equivalent to False.

Yes it does. Python has no way to know what would be the most
usefull Boolean interpretation of these values in a particular
context. That it picks one out is guessing. Lisp imterprets
an empty list as false, scheme interprets it as true. So
both seem usable interpretations.

> If your 
> function is capable of validly returning any of these values then your 
> calls must be prepared to discriminate between (say) zero and False or 
> None. If not, the calling experession in the "if" can be simpler.

But that doesn't seem to be accepted practice in this newsgroup.
Whenever someone shows code that does something like:

  if var != []:
    ...

or

  if var is True:

Someone else is almost bound to react that it is better to
write this as:

  if var:


IMO it is the fact that python accepts almost anything as
true that may make it necessary to use "var is True"

>>>That is not the case with
>>>fileobject read(), nor with many functions in Python that
>>>reasonably and ideally return a value of a type that may
>>>meaningfully test false.  In this case, comparison (==) with
>>>the false value ('') is silly.
>> 
>> 
>> No is is not. The comparison with the specific false value
>> makes it easier for the reader of the code to find out what
>> to expect. I also find the use of '' as false in this context
>> wrong. A read can be used on all kind of objects including
>> a network connection. Returning '' on a network read would
>> be IMO the most natural answer to say, the network connection
>> is still open but no data is available for the moment. '' here
>> would mean "nothing yet" while '' is now made into "nothing more"
>> 
> Yes, but you are restricting the programmer's range of expression if you 
> promote this as a general rule. Sometimes it's important to discriminate 
> between "", (), [] and None, sometimes there is no possiblity that 
> confusion will arise.
>
> When there's no possibility of confusion you arae just picking nits 
> (which I know your sense of intellectual tidiness encourages you to do ;-).

IMO there is more possibility of confusion then you think off.

Sure if you restrict your attention to one specific part of code, you
can conclude that there is no possibility of confusion whether '' is
used as false or not. But maybe sometime in the future you would want
that piece of code to work with other pieces of code where it is not
usefull to have '' interpreted as false in a Boolean context. 
Now suddenly whether '' is false or not depends on where it is coming
from and your code with no possibilty of confusion is part of
a project where it is contributing to the confusion.

-- 
Antoon Pardon