if the else short form

[Antoon Pardon]

On Tue, Oct 05, 2010 at 06:55:33PM +1300, Lawrence D'Oliveiro wrote:
> In message <mailman.1232.1285927634.29448.python-list at 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