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 :-) > 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. > 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. 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. 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. -- https://mail.python.org/mailman/listinfo/python-list
