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. -- http://mail.python.org/mailman/listinfo/python-list
