On 4/8/21 2:40 PM, Chris Angelico wrote:
At least in this form, it's clear that there's a sharp distinction
between the stuff around the outside of the 'with' block and the stuff
inside it.
The semantics, as suggested, give 'with' blocks two distinct
exception-management scopes, which mostly but do not entirely overlap.
It's not a problem to rigorously define the semantics, but as
evidenced here, people's intuitions will vary depending on which
context manager is being used. It's absolutely obvious that the OP's
example should let you catch errors from open(), and equally obvious
that suppressing BaseException should mean that nothing gets caught.
That's the problem here.
As such, I'm -0.5 on this. It's a kinda nice feature, but all it
really offers is one less indentation level, and the semantics are too
confusing.
I, on the other hand, would love for something along those lines -- I find it massively annoying to have to wrap a
with-block, which is supposed to deal with exceptions, inside a try/except block, because the exceptions that `with`
deals with are too narrowly focused.
Of course, I also prefer
def positive(val):
"silly example"
if val > 0:
return True
else:
return False
over
def positive(val):
"silly example"
if val > 0:
return True
return False
because the first more clearly says "either this happens, or that happens". Likewise, having the excepts line up with
the `with` visually ties the code together.
Granted, this mostly boils down to personal preference.
--
~Ethan~
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3JIGEJAEAJIQXITUCMSKH2ZOK6WSUGJS/
Code of Conduct: http://python.org/psf/codeofconduct/
