while c = f.read(1)

[Antoon Pardon]

Op 2005-08-24, Magnus Lycka schreef <lycka at carmen.se>:
> Antoon Pardon wrote:
>> Such a PEP would have no chance of being accepted, since
>> it would break to much existing code.
>
> What's the point of this thread then?

I only hope to impress people that the way python
treats 'nothing' in a condional context is not
so obvious as seems to be accepted here.

>> But how can you do this when somewhere else '' is used as
>> an indication for an EOF.
>
> If that's your problem, I guess that's what you should attack,
> not that Python considers nothing to be nothing even it might
> some time become something.

IMO the two are linked. People use '' as an EOF because the
call they are working with returns strings and they need a
way to end a loop. Since "if var:" is considered beautifull
they search for a nothing value and since they were working
with strings, '' gets chosen.

> Network programming with Python works pretty well though, so
> it seems this is a non-issue too.
>
>>>I think the typical comment is to replace "if s != '':" with
>>>"if s:" in contexts where s is always a string,
>> 
>> And it is IMO this kind of comments that lead to '' being used
>> as an EOF.
>
> Huh? Aren't the Python APIs just mirroring the behaviour of the
> underlying C APIs?

That may depend on how strict the meaning of mirroring is, you
are using. I would say no. Even if the answer is yes I would
say that chosing such values on that basis was a bad design
choice.

>>>or to replace
>>>"if expr != False:" with "if expr": in cases where "expr" is an
>>>expression that returns True or False etc. In some cases, obvious
>>>bugs, such as "if (a and b) == True:" where the programmer
>>>should have written "if (a and b):" are pointed out.
>> 
>> This is not such an obvious bug. Because python allows non boolean
>> operands with "and" the two don't behave the same. How do you know
>> which behaviour the other person wants?
>
> I think you misread my text. If the programmer should have written
> "if (a and b):", adding "==True" will cause different behaviour
> unless True (or 1) is the only non-False value that b can have.
> This would not be obvious for someone who expects that the results
> of logical operations will return boolean values.

So? How do you know what the writer of the code expects. You
originaly wrote it was an obvious bug, how do you come to
that conclusion.

>> I have yet to see a mathematical work where 0, or any kind of
>> empty sequence is treated as false. In mathematics accuracy
>> is considered vitaly important and won't be sacrified to
>> remove redundancy. Boolean expression are always written out
>> fully.
>
> Dear Antoon. The "if" statement interprets the result of an
> expression to determine whether or not to execute a block of
> code. If "x" is an expression that returns True or False, then
> "x==True" is an equivalent expression. It's just not written in
> its minimal form.

But we were talking about interpreting 0, '', (), [], and {}
directly in a conditional context. No mathematical text
will just contain a line like

  a  =>  b > 10
  
when what is meant is:

  a != 0  =>  b > 10

> It's like writing "a / b * 100 %" instead of just "a / b" in a
> mathematical equation. The first version contains some kind of
> noise that just looks ugly for people who know that 100%==1.
> Why multiply with 1? At least in my home town, the MBA students
> write stuff like that, but mathematicians and engineers would
> just think it was ugly.

But you can't transfer this situation to python, because python
allows non Boolean values to be interpreted in a conditional
context. I have code somewhere that looks like this:

  if var is True:

and that is exactly how it should be. The if branch should not
be taken if var would be 5. I even have code that looks like:

  if var is not False:

And although in a logical context those two would be equivallent
to each other and to just "if var:", they are not equivallent
in a python context. 

Yet I see a lot of suggestions here to change logical expressions
in python code, seemingly based on the fact that they would
be equivallent in a logical context.

>> But you don't know if the logic expression are redundant. The
>> suggestions made are usually not equivallent.
>
> I think I know. Please point out if I made some mistake.
>
> It's pretty common that people fail to reduce logical expressions.
> I've seen C++ code checking for overlapping periods looking roughly
> like this:
>
> if ((start1<=start2 and stop1>=start2 and stop1<=stop2) or
>      (start1<=start2 and stop1>=stop2) or
>      (start1>=start2 and stop1<=stop2) or
>      (start1>=start2 and start1<=stop2 and stop1>stop2))
>
> For that person, his code might actually have been clearer than
> the less cluttered version I changed it to:
>
> if (start1<=stop2 and start2<=stop1)
>
> At least he spent a few minutes staring at it before he could
> accept that they were equivalent. (Maybe he just gave up.)

I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

  start1=67, stop1=9, start2=10, stop2=29

>> In that case you wouldn't return an empty sequence if you wanted
>> a false value in a sequence context but would throw an exception.
>
> Huh? If I want False I use False. If a sequence is empty, it's empty.
> It seems to me that you make things more complicated than they have
> to be.

You can't just decide to use False if you want False. What if
you depend on a library that returns '', because '' behaves
as false in a conditional context. So returning it was good
enough for those who wrote it.

-- 
Antoon Pardon