[Calvin Spealman]

Why not allow excepts on fo loops, for example?

Why not, indeed... I've heard there's a non-insignificant performance penalty for setting up a try statement, so it might be important to only set a for-loop up as a guarded for-loop upon reading the "except" statement (if the compiler can handle such behavior). On Tue, Jan 22, 2019 at 2:24 PM Calvin Spealman wrote:

On Tue, Jan 22, 2019 at 3:11 PM Paul Ferrell 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 https://red.ht/sig TRIED. TESTED. TRUSTED. https://redhat.com/trusted _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

You could write a context manager that used an arbitrary callback passed in to handle exceptions (including re-raising as needed). This doesn't require new syntax, just writing a custom CM. On Tue, Jan 22, 2019, 4:20 PM Barry Scott

On 22 Jan 2019, at 20:31, Michael Selik wrote:

On Tue, Jan 22, 2019, 12:11 PM Paul Ferrell

...

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.

The time machine strikes again. In fact, you can handle exceptions with a context manager object. Whatever you're with-ing must have a dunder exit method, which received any exceptions raised in the block as an argument. Return true and the exception is suppressed.

Suppressing the exception is not the general case. And will not work for the example given.

Barry

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

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

That is definitely an ambiguity worth considering (whether __enter__ is within the implied 'try'). Anecdotally, I showed the with/except example to my student (who's relatively new to python), to see how he interpreted it. He (correctly?) assumed the CM operations were within the 'try', and was pretty surprised when I told him that the except part of the with wasn't actually valid Python. On Tue, Jan 22, 2019 at 2:30 PM Chris Angelico wrote:

On Wed, Jan 23, 2019 at 7:11 AM Paul Ferrell wrote:

...

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(...)

Edge case: The "try/with/except" structure includes the entire 'with' header inside the try block, including the call to open(). But if the with block itself is handling the exceptions, the expression "open(path)" is actually evaluated before the exception handling gets going. So adding an except clause is NOT the same as just adding another context manager to the stack.

I'm -0.25 on it, as I don't think overlaying in this way improves clarity. The current syntax makes it very obvious that the "open(path)" call is inside the try/except, but the proposed syntax isn't so clear (and as many people will expect it to be inside as outside).

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Paul Ferrell pflarr@gmail.com

On Tue, Jan 22, 2019 at 03:22:27PM -0700, Paul Ferrell wrote:

Anecdotally, I showed the with/except example to my student (who's relatively new to python), to see how he interpreted it. He (correctly?) assumed the CM operations were within the 'try', and was pretty surprised when I told him that the except part of the with wasn't actually valid Python.

One of the more pernicious myths about language design is that if something surprises a beginner, it must be a bad idea. The reality is that beginners are the worst people to judge what is good or bad or consistent, because they don't have the knowledge or experience to recognise deep consistency or flaws in an feature. I'm just making a general observation here, not making a specific claim that this specific proposal is flawed (beyond the point I made earlier that it may be unnecessary and redundant). But anecdotes about "beginners were surprised by..." don't carry much weight with me. (Not "zero weight", it isn't as if I *want* to surprise beginners, and sometimes newcomers to a language can spot things which experts are so used to they don't notice any longer.) -- Steve

On Jan 22, 2019, at 8:28 PM, Steven D'Aprano wrote:

I've been thinking more about this proposal, and realised why I've been feeling a slight sense of disquiet about it. I think it encourages an anti-pattern of catching too much. (Or at least a code smell.)

Although we're all guilty of violating this principle from time to time, in general we ought to surround the minimum amount of code with a try...except that we need. Ideally (but rarely possible in practice) we want to surround a single operation which might raise at a time.

I ended up at a similar conclusion this morning. I'm wary of enclosing too much code in the try block since it makes handling exceptions very difficult unless you have a rich hierarchy of exceptions -- something that I also warn against. I view the problem of enclosing too much in the try block as an extension of an overly broad except block. It makes it nearly impossible to know where the exception came from so you cannot handle it safely unless you have an exception hierarchy where each exception is raised from a single place in the code. A similar anti-pattern that I see regularly is to *catch too often* where there is a try-catch block every time that a method from another module or library is called and the catch portion translates the exception instead of handling it. It's interesting that the "exception translator" pattern leads to an overly rich exception hierarchy. It is interesting that you mention whether the try-catch would wrap __enter__ or not. The main reason that I am -1 on this proposal is that it introduces more ambiguity in what is happening. I was about to write pretty much what you have written with regards to the syntax muddying the waters about the scope of exception handling especially with regards to the meaning of the return value of `context_manager.__exit__`

But the alternative is to enshrine in syntax something which *by design* guards too much and is a code smell.

Very well put ;) - dave -- Safe wiring is not something to be learned after the fire trucks have left.