On 22Dec2013 16:53, Roy Smith <r...@panix.com> wrote:
> In article <mailman.4512.1387748397.18130.python-l...@python.org>,
> Cameron Simpson <c...@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 <c...@zip.com.au>
I must construct my own System, or be enslaved to another Man's.
- William Blake
--
https://mail.python.org/mailman/listinfo/python-list
