cascading python executions only if return code is 0

[Cameron Simpson]

On 22Dec2013 16:53, Roy Smith <roy at panix.com> wrote:
> In article <mailman.4512.1387748397.18130.python-list at python.org>,
>  Cameron Simpson <cs at 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 at zip.com.au>

I must construct my own System, or be enslaved to another Man's.
        - William Blake