while c = f.read(1)

[Magnus Lycka]

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

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

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

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.

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.

Concerning interfaces between different pieces of code, it's a
good approach to assume as little as possible, but to be clear
about what we assume.