Op 2005-08-23, Magnus Lycka schreef <[EMAIL PROTECTED]>: > 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 -- http://mail.python.org/mailman/listinfo/python-list
