The thing that concerns me is that any such problem and solution seems
to apply equally to any other kind of block. Why not allow excepts on fo
loops, for example?

Very good point.

I think 'with' is special in that it typically contains the entirety of the use of an object, and the type of objects one tends to use in a 'with' are prone to throwing exceptions. Other statements like it don't intrinsically encapsulate the usage of an object.

On Tue, Jan 22, 2019 at 1:23 PM Calvin Spealman <cspealma@redhat.com> wrote:


On Tue, Jan 22, 2019 at 3:11 PM Paul Ferrell <pflarr@gmail.com> wrote:
I've found that almost any time I'm writing a 'with' block, it's doing
something that could throw an exception. As a result, each of those
'with' blocks needs to be nested within a 'try' block. Due to the
nature of 'with', it is rarely (if ever) the case that the try block
contains anything other than the with block itself.

As a result, I would like to propose that the syntax for 'with' blocks
be changed such that they can be accompanied by 'except', 'finally',
and/or 'else' blocks as per a standard 'try' block. These would handle
exceptions that occur in the 'with' block, including the execution of
the applicable __enter__ and __exit__ methods.

Example:

try:
    with open(path) as myfile:
      ...   # Do stuff with file
except (OSError, IOError) as err:
    logger.error("Failed to read/open file {}: {}".format(path, err)

The above would turn into simply:

with open(path) as myfile:
    ... # Do stuff with file
except (OSError, IOError) as err:
    logger.error(...)


It definitely makes sense, both the problem and the proposed solution.

The thing that concerns me is that any such problem and solution seems
to apply equally to any other kind of block. Why not allow excepts on fo
loops, for example?
 

I think this is rather straightforward in meaning and easy to read,
and simplifies some unnecessary nesting. I see this as the natural
evolution of what 'with'
is all about - replacing necessary try-finally blocks with something
more elegant. We just didn't include the 'except' portion.

I'm a bit hesitant to put this out there. I'm not worried about it
getting shot down - that's kind of the point here. I'm just pretty
strongly against to unnecessary syntactical additions to the language.
This though, I think I can except. It introduces no new concepts and
requires no special knowledge to use. There's no question about what
is going on when you read it.

--
Paul Ferrell
pflarr@gmail.com
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


--

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspealma@redhat.com  M: +1.336.210.5107



--
Paul Ferrell


--
Paul Ferrell