On Jul 29, 2019, at 12:24, Dominik Vilsmeier <firstname.lastname@example.org> wrote:
> I could imagine that due to the awkward workaround, especially regarding `with`, corresponding "self-made" code is either error-prone or people will not even try to work around it in the first place. This feature will probably be among the less prominent ones, but someone who needs it will be glad that it exists and they're also likely to be well aware of what it does (just like with `for ... else`).
I think it’s a problem if this feature is accepted at a level more or less akin for for…else.
The problem that for…else solves is a bit clunkier to solve without it, but not that bad—novices can and do figure out how to write correct code without else. So, while it’s a shame so many people never learn to use it, it’s not a huge deal.
The problem that with…except solves is so much harder to solve without it that even experienced developers usually just punt and try…except the whole block around the with. That’s a lot worse. And this isn’t a rare thing; it comes up all the time in all kinds of code. So it really calls for a syntax that most people will learn to use, not something like for…else that some experts use but most people live without.
I am *guessing* the problem here is something like this:
with open(filename) as f:
data = f.read()
raises an exception if the open() call fails, but putting try... except IOError: ... around the whole thing also catches I/O errors in the read() call (or anything else you might put in the body). Other solutions are more verbose and run other risks. For other types of context managers it may be worse because the error you want to catch occurs in the __enter__() call that's implicit in the with-clause (for open(), __enter__() is just "return self" since all the work happens before).
Still I wouldn't call this "a lot worse". What makes you say that?
(But I don’t have a better syntax to offer. I actually like with…except, if it were just for my use, but on reflection I can see why others find it confusing. Just like for…else.)
In hindsight I probably added for..else prematurely; it would never be accepted now. But at this point there would be a cost at removing it as well and I don't think that's worth considering. But if the bar is about as high for with...except as it would be if for...else was proposed today, then I think it's clear we should not add with...except (nor for...except, whose use case is much weaker IMO).