[lug] Python: Unable to catch subprocess error

Jed S. Baer blug at jbaer.cotse.net
Sat Mar 10 10:10:00 MST 2018


On Sat, 10 Mar 2018 07:51:47 -0700
Rob Nagler wrote:

> It's why I say programming in Python is like being inside a Monty Python
> sketch. You never know what's going to happen next, and none of it makes
> any sense, but if you keep your sense of humor about you, it's a barrel
> of laughs! How about this for something completely different: Python 2
> and 3 have very different string types (ha ha!) so you might use
> types.StringTypes to ensure forward compatibility between the two
> versions except that types.StringTypes went away in Python 3. In fact
> the semantics of the module "types" change completely from Python 2 to
> 3. That's some really silly programming!
> 
> The relevant point to this thread is that reading the source code
> doesn't give a clue as to why shell=True changes the semantics of
> "program not found" exception handling in Python. It's actually just
> lazy programming. To make the semantics equivalent in the two cases,
> _execute_child (the POSIX version) should parse the exit code of
> "/bin/sh -c" (127 is a known exit status for program not found
> <http://tldp.org/LDP/abs/html/exitcodes.html>). A newbie can't be
> expected to see that code to handle this special case is not there.

I appreciate the followup, and I hope it was at least as enjoyable as
watching Brazil. As much as I like that movie, it doesn't represent the
experience I'm looking for when trying to write code. :)

But more seriously, it would seem that those writing things for Python
are unfamiliar with the principle of least surprise. I will grant that
sometimes, and in particular when trying to be cross-platform, there are
edge cases which can produce unexpected situations, but failing to carry
an exception up through the call stack shouldn't fall into this category.

"Quite agree. Too silly, too silly."
/me returns to his pipe


More information about the LUG mailing list