On Sun, May 31, 2020 at 06:45:01AM +1000, Chris Angelico wrote:
On Sun, May 31, 2020 at 6:14 AM Mike Miller email@example.com wrote:
On 2020-05-28 18:02, Greg Ewing wrote:
If __name__ == '__main__': sys.exit(main(sys.argv[1:]))
It's not clear that exiting with the return value of main() is the most Pythonic thing to do -- it's more of a C idiom that
If you'd like a script to be uhh, highly-scriptable, returning one of the os.EX_* status codes can be useful to communicate back to the calling shell what happened.
First catch the exceptions, convert to the appropriate status code, then return at the end.
OR! You could just do nothing. And then, if SystemExit is raised,
Well, that's very fine and good, but the chances are remote that SystemExit will be raised if I do nothing. More likely it will be some other exception.
In order to raise SystemError, you need to catch the exception that actually occurred, convert it to an os.EX_* error code, and at that point it's entirely up to you whether you return from main() and let the sys.exit() wrapper handle the exit, or call sys.exit directly.
Here's my preference: a function can have many returns, and that's fine. But an application should only have one (or at most a few) exit points, and they should never, ever be buried inside a function that someone might want to call.
What's wrong with this test code? It's buggy. Can you see why?
Python will return that exit code to the calling process (whether it's a shell or not). Python even provides a convenient function sys.exit for raising SystemExit with a specific code...
I'm not entirely sure, but I *think* that both "tritium-list" and Mike may be aware of this, since they are calling sys.exit to do precisely that *wink*
Don't catch what you can't deal with.
That's good advice, but how does it apply here since Mike clearly can deal with the exceptions. He even tells you what he does:
"First catch the exceptions, convert to the appropriate status code, then return at the end."
Which seems like excellent advice to me.