On 2009-07-02, Scott David Daniels <scott.dani...@acm.org> wrote: > Duncan Booth wrote: >> Simon Forman <sajmik...@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. -- http://mail.python.org/mailman/listinfo/python-list