while c = f.read(1)

[Antoon Pardon]

Op 2005-08-23, Magnus Lycka schreef <lycka at carmen.se>:
> Antoon Pardon wrote:
>> Following a well defined specification is not contradictory
>> to guessing. It may just mean that the guess was formalized
>> into the specification.
>
> If you want the behaviour of Python to change, you should
> write a PEP.

Such a PEP would have no chance of being accepted, since
it would break to much existing code.

> It always felt natural to me to interpret empty
> as false, but I could be wrong. It's strange that this flaw
> managed to go unnoticed for so long though...

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

> If Python is too "wild" for your taste, you might like OCaml.
>
>> Well then I must say people here give beauty too high a priority.
>> Because there seems a tendency to beautify others code when
>> snippets are posted here. Often enough such snippets
>> don't give enough inoformation to know whether "if var is True:"
>> can be replaced by "if var:" or whether other beautifications are
>> appropiate. 
>
> You might be right about that. I didn't really notice.
>
> 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.

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

> Many of us have a solid mathematical education, and in that world
> it's considered good behaviour to simplify expressions and remove
> redundancy.

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.

> If we see things such as redundant pieces in logic expressions,
> functions ending in "return None", returns directly after a raise,
> or other meaningless constructs, it suggests that someone might be
> doing something they don't understand, and then it's helpful to
> try to point that out.

But you don't know if the logic expression are redundant. The
suggestions made are usually not equivallent.

> It's really important to understand what we do when we're
> programming, not just repeat mantras or wave dead chickens.
>
> If people mechanically learn "I shouldn't use '!= False' in
> if-statements in Python", we've failed in trying to help them.
> If people learn what Python considers true and false, what the
> boolean operators return, and understands how to use these
> things in an effective way, we've succeeded.
>
> Another aspect of this particular idiom is that it's often better
> to use the exception system in Python for exceptional situations,
> than to use one variable to carry several different kinds of
> information.

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

-- 
Antoon Pardon