On Tue, Oct 05, 2010 at 06:55:33PM +1300, Lawrence D'Oliveiro wrote: > In message <mailman.1232.1285927634.29448.python-l...@python.org>, Antoon > Pardon wrote: > > > On Wed, Sep 29, 2010 at 01:38:48PM +0200, Hrvoje Niksic wrote: > > > >> BTW adding "==True" to a boolean value is redundant and can even break > >> for logically true values that don't compare equal to True (such as the > >> number 10 or the string "foo"). > > > > But leaving it out can also break things. > > Only in code which was incorrectly written to begin with.
Well you can always define such code as incorrectly written of course. I find it odd that on the one hand, if static types get mentioned, the python people in general are against it because they like the freedom that a variable can be bound to objects of different types. But then when they see code, that explicitly checks for "True" and thus might make use of that possibility and as such behave differently in case of "True" or non-zero number values, the reaction is to consider that incorrectly written code by definition. Personaly I don't see a reason to declare in advance that someone who wants to treat "True" differently from non-zero numbers or non-empty sequences and does so by a test like: if var == True or if var is True to have written incorrect code. The designers have chosen that a lot of different results act as true in a boolean context. A programmer trying to solve a particular problem doesn't necessary want to treat als those possible results the same. So if the programmer wants to treat True differently from those other true-results I don't see an other option than using a test like above. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
