Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 27 May 2013 11:57:54 +1000
From: Cameron Simpson <cs@zip.com.au>
To: Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Subject: Re: Short-circuit Logic
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51a2ab67$0$30002$c3e8da3$5496439d@news.astraweb.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
References: <51a2ab67$0$30002$c3e8da3$5496439d@news.astraweb.com>
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2228.1369621763.3114.python-list@python.org>
Lines: 68
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:46156

On 27May2013 00:40, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
| On Sun, 26 May 2013 16:22:26 -0400, Roy Smith wrote:
| 
| > In article <mailman.2196.1369599562.3114.python-list@python.org>,
| >  Terry Jan Reedy <tjreedy@udel.edu> wrote:
| > 
| >> On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
| >> 
| >> >       if not allow_zero and abs(x) < sys.float_info.epsilon:
| >> >                  print("zero is not allowed")
| >> 
| >> The reason for the order is to do the easy calculation first and the
| >> harder one only if the first passes.
| > 
| > This is a particularly egregious case of premature optimization.  You're
| > worried about how long it takes to execute abs(x)?  That's silly.
| 
| I don't think it's a matter of premature optimization so much as the 
| general principle "run code only if it needs to run". Hence, first you 
| check the flag to decide whether or not you care whether x is near zero, 
| and *only if you care* do you then check whether x is near zero.
| 
| # This is silly:
| if x is near zero:
|     if we care:
|         handle near zero condition()
| 
| # This is better:
| if we care:
|     if x is near zero
|         handle near zero condition()
| 
| 
| Not only is this easier to understand because it matches how we do things 
| in the real life, but it has the benefit that if the "near zero" 
| condition ever changes to become much more expensive, you don't have to 
| worry about reordering the tests because they're already in the right 
| order.

I wouldn't even go that far, though nothing you say above is wrong.

Terry's assertion "The reason for the order is to do the easy
calculation first and the harder one only if the first passes" is
only sometimes that case, though well worth considering if the
second test _is_ expensive.

There are other reasons also. The first is of course your response,
that if the first test fails there's no need to even bother with
the second one. Faster, for free!

The second is that sometimes the first test is a guard against even
being able to perform the second test. Example:

  if s is not None and len(s) > 0:
    ... do something with the non-empty string `s` ...

In this example, None is a sentinel value for "no valid string" and
calling "len(s)" would raise an exception because None doesn't have
a length.

With short circuiting logic you can write this clearly and intuitively in one line
without extra control structure like the nested ifs above.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

Who are all you people and why are you in my computer?  - Kibo