On Tue, 30 Jul 2019 at 04:00, Ethan Furman <ethan@stoneleaf.us> wrote:
If this "with...except" leads to more robust code then I think many would like to use it, but not if it's confusing as that would lead to less robust code.
For me, "it's for robust code" is sufficient hint that I now remember what it does (much the same way that "it's for search loops" is the hint I need for for...else). And when I'm trying to write robust code, I *do* worry about exceptions in the with expression, and the fact that I can't easily catch them. So for me, this is definitely a real (albeit one I can usually ignore) problem. The thing is that for most of the code I write, it's not *that* important to be highly robust. For command line interactive utilities, people can just fix unexpected errors and rerun the command. So putting a lot of effort into robustness is not that important. But then someone scripts your utility, and suddenly tracebacks are a much bigger issue. That's why the with statement is so useful - it makes robust exception handling low-cost to write, so my code moves a step closer to robust-by-default. This proposal takes that a step further, by lowering the cost of a tricky bit of boilerplate. So I don't think it's essential, but I *do* think it would be a useful addition to the language. On the other hand, for...except has much less appeal, as I don't think of for loops as blocks of code where I'd expect to be able to control what exceptions escape (whereas in my mind that's a primary feature of the with statement). Paul