Op 2005-08-22, Magnus Lycka schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >>>Python doesn't guess. There are a range of values that will be treated, >>>in a Boolean context (how perlish) as equivalent to False. >> >> Yes it does. > > No it doesn't! > >> Python has no way to know what would be the most >> usefull Boolean interpretation of these values in a particular >> context. > > It's hardly the task of the interpreter to try to do that.
Indeed ir is not, so the interpreter should not pretend it can by providing a Boolean interpretation. >> That it picks one out is guessing. > > No, it simply follows a well defined specification. > See http://docs.python.org/ref/Booleans.html > There is no guessing involved in that. Following a well defined specification is not contradictory to guessing. It may just mean that the guess was formalized into the specification. >> Lisp imterprets >> an empty list as false, scheme interprets it as true. So >> both seem usable interpretations. > > You might argue that *Guido* was guessing when he decided what > the most useful behaviour of Python would be in this case, and > there's probably some truth in that, just as there is some > guesswork involved in most programming language design decisions, > but that's another thing. That's not Python guessing, it's > Guido using his excellent lanugage design skills. It seems most > Python programmers agree that he "guessed" right here, as usual. I don't see a big difference. Guessing plays its roles when different people can have different expectations in cases where not all the details are known/specified. Whether that is in the language design or in program design doesn't make a big difference and I would expect that a language that discourages guessing in the software that its written in it, would follow its own rules in its design. > (Perhaps you thought that "Python" was the name of the language > designer. It's not. Python's design is led by Guido van Rossum, > and the name Python comes from a (mostly) British comedy group.) > > You might also argue that this behaviour is counter to the > Python dogma of "explicit is better than implicit". Python also > allows you to get a float out of an expression such as "2*3.1" > without forcing an explicit cast, as in "float(2)*3.1". > > You should note that the first Python tenet is "Beautiful is > better than ugly" and that's probably what we have to blame here. > > There seems to be close to a consensus, that "if users:" is more > beautiful than e.g. "if len(users) > 0:" or > "if (len(users)==0)==False" or for that matter > "if ((len(users)==0)==False)==True" or > "if (((len(users)==0)==False)==True)==True" etc. 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. > What's true and false for Python, belongs to the few things you > actually have to learn, and I can appreciate that it's annoying > for a frequent schemer to remember that it's not the same in > Python, but it seems that very few people argue with the way > Python behaves in this respect. I care very little for what someone with experience in an other language can expect. I care about the consistence of the language and the programs written in it. I just mentioned scheme to show that [] interpreted as false is not so obvious as a lot of people seem to think. Since there are situations where using '', (), [] or 0 as false would be not appropiate I advise against using them as such, because you never know when your software that does has to cooperate with software that doesn't. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
