Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 23 Dec 2013 09:11:25 +1100
From: Cameron Simpson <cs@zip.com.au>
To: Roy Smith <roy@panix.com>
Subject: Re: cascading python executions only if return code is 0
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <roy-2E9B79.16533122122013@news.panix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
References: <roy-2E9B79.16533122122013@news.panix.com>
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4513.1387750297.18130.python-list@python.org>
Lines: 83
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:62557

On 22Dec2013 16:53, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4512.1387748397.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
> > Roy's code _depends_ upon the return value being equivalent to False.
> 
> Yes.  You view this as a flaw.  I view it as a feature :-)

When I write functions which return a boolean indicating success/failure,
I try to make that boolean be "true" for success.

Now, I do take the point that these functions seem to take the
unix-exit-code convention that zero is success (leaving the many
values of "non-zero" to indicate flavours of failure as desired,
as we have many types of exceptions).

Or, possibly, that a non-zero return indicates the number of errors
encountered; I do that myself for things like option or file parsing,
where I explicitly want to parse of much of a command line (or
whatever) as possible before rejecting things; few things annoy me
as much as a command that barfs about the first usage error and
aborts instead of barfing multiple times and aborting. Unless it
is a command that does the same and then fails to recite a usage
message after the barf. (Yes, almost every GNU command on the planet:
I'm looking at you!)

However, in this count-of-errors scenario I tend to try to return
a list of errors, not a count.

But regardless, I consider code that goes:

  a() or b() or c()

as a test for _success_ of a(), b() and c() in succession to be
misleading at best. When I write that above incantation it is a
test for failure: try this, or try that, or finally try this other
thing.

> > A better approach would be:
> > 
> >   a() == 0 and b() == 1 and c() == 0
> > 
> > i.e. to explicitly check each return code against the expected/desired
> > value instead of relying on some flukey coincidental property of
> > the (arbitrary) numeric value returned.
> 
> You're assuming it's arbitrary.  I'm saying do it that way by design.  

The counter example the above is based upon deliberately returned
1 for success from b(), IIRC. Different design.

The OP was unclear about his/her design rationale.

> > Better still is the suggestion elsewhere in the thread to make the functions
> > raise exceptions on error instead of returning a number.
> 
> Possibly.  But, I think of exceptions as indicating that something went 
> wrong.

I think of failure as "something went wrong".
Yes, I'll grant there are shades of intent here.

> There's two possible things the OP was trying to do here:
> 
> 1) He intends that all of the functions get run, but each one can only 
> get run if all the ones before it succeed.  In that case, I agree that 
> the exception pattern makes sense.

His cascading if-statement in the OP suggested this to me.

> 2) He intends that each of the functions gets tried, and the first one 
> that can return a value wins.  If that's the case, the "or" chaining 
> seems more natural.

I'm pretty sure that wasn't his intent, again based on my recollection
of the OP. But I still dislike "a() or b() or c()" as a test for
chained success; I think it is a bad idiom.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

I must construct my own System, or be enslaved to another Man's.
        - William Blake