question of style

Tim Harig usernet at ilthio.net
Thu Jul 2 16:27:33 EDT 2009


On 2009-07-02, Scott David Daniels <Scott.Daniels at Acm.Org> wrote:
> Duncan Booth wrote:
>> Simon Forman <sajmikins at gmail.com> wrote:
>> As a matter of style however I wouldn't use the shorthand to run two 'is' 
>> comparisons together, I'd write that out in full if it was actually needed 
>> here.

That part I don't really have a problem with.  The chained is statements
can actually be much clearer burying the tests into nested ifs.  Nested ifs
get the same result but they also give an immediate impression that the
control structure might be looking for more then a single test result.  I
have to walk through the ifs to see all of the potential results one is
looking for before I know what the entire control struture is doing.
Multiple is operators makes it clear that I just want everything to be the
same.  The same would not be true if the operators where not all equilance
operators ( is and == are clear as long as they are not mixed; but <, >=,
!= would be more confusing).

> Speaking only to the style issue, when I've wanted to do something like
> that, I find:
>        if self.higher is None is self.lower:
> more readable, by making clear they are both being compared to a
> constant, rather than compared to each other.

By comparing them to *any* constant with 'is' you end up with the same
potential problems as to whether something with a value of None is actually
None?  Is something with the value of 3 actually the same object as 3?
What about if I make a deep copy?  Can I have several objects with the
value of three, all the same 3 object, or maybe even a combination of 1
separate 3 object with two other objects of the same 3.

Is
	if self.higher == None == self.lower:
any more clear then:
	if self.higher == self.lower == None:
I don't personally have a problem with either.

> More often, I've used code like:
>        if <expr1> is not None is not <expr2>:
> since I am usually working on non-defaulting cases in the body.
> I find the form above simpler to read than:
>        if <expr1> is not None and <expr2> is not None:

This is a much more compicated expression.  With equality operators
everything is either the same or it isn't.   I can start from the first
variable and compare it to the second then to the third then ...  In the
case of the inequality, I have to start with the first and compare it to
all of the rest to make sure that none are the same.  Then I have to do the
same for each with the remaining.  This is much more difficult to do in my
head.  I requires much more thought, better left to a computer, when
evaluating the expression for myself.  Therefore, equalites are quick and
easy to keep straight whereas any inequalites are more error prone when
trying to evaluate how a section of code will react under different
circumstances.

> I do draw the line at two, though, and with three or more I'll
> paren-up a list of parallel comparisons:

As long as everything is an equality, then I don't mind comparing to the
end of an 70 column line.  Mixed types of equalities or inequalities
require too many operations mentally evaluate safely.



More information about the Python-list mailing list