[Python-ideas] Fwd: Potential PEP: with/except
Paul Ferrell
pflarr at gmail.com
Tue Jan 22 17:15:50 EST 2019
>
> 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 at redhat.com> wrote:
>
>
> On Tue, Jan 22, 2019 at 3:11 PM Paul Ferrell <pflarr at 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 at gmail.com
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspealma at redhat.com M: +1.336.210.5107
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
--
Paul Ferrell
pflarr at gmail.com
--
Paul Ferrell
pflarr at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190122/f41d1e5e/attachment-0001.html>
More information about the Python-ideas
mailing list