while c = f.read(1)

[Magnus Lycka]

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?

> 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.

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?

>>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.

> 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.

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 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.)

Of course, it might well be that different brains work in different
ways, and that different presentations are preferred by different
people. Python seems to fit my brain.

In the overlapping case above it's really a shift of perspective.
He saw overlapping time periods as occuring in four different
cases:
  * A starts before B and ends during B
  * A starts before B and ends after B
  * B starts before A and ends during A
  * B starts before A and ends after A.

I guess my first impulse (before I asked what his code did) was
that it looked redundant, but the thing is that my short version
describes overlapping time periods in a different way: Both
periods start before the other period ends. That's all!

The kinds of simplifications in code that we talk about often has
this quality. They show us that things are really simpler than the
coder thought. I'm sure it happens that some people try to over-
simplify things, but most systems can be made simpler, and trying
to do that is a noble cause.

> 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. Perhaps you're just confused over the C APIs for network
programming. I can understand that, but you seem to be pretty far
away from the real target now.

> So this would be fine by me, I just don't understand how this
> would support the use of empty sequences as false.
> 
> I also don't see how a read from a network connection returning
> either:
> 
>   a bytestring    when data is available, 
>   ''              when no data is available
>   None            when the connection was closed
> 
> As so much different kinds of information.
> 
> Besides sometimes different kinds of information is not that
> exceptional, so why should I throw an exception in such a
> case?

I don't know what you are trying to say. If you want more
Pythonic network API, I'd rather use an iterator. Just make
it return StopIterator when the connection closes. You would
use it like this:

for chunk in NetworkReader(ip, port):
    if chunk: print chunk

This could be blocking, or use a timer and return '' on
timeout. Thus the if-statement. chunk would always be a
string. As you suggested, an empty string would then mean
no data yet. When the connection is closed, the for loop
simply ends.

In this context, writing "if chunk != '':" instead of simply
"if chunk:" is just a waste of resources.