On 4/8/21 11:25 AM, Chris Angelico wrote:

Similar question: What would be the semantics of this?

with contextlib.suppress(BaseException): a = b / c except BaseException as e: print(e)

What types of exception could be caught and what types couldn't?

Well, if every exception is derived from BaseException (they are) and contextlib.suppress(BaseException) suppresses all BaseException-derived exceptions (it does) then the semantics of the above are: - "a" will be the result of "b / c" if no exception occurs - otherwise, "a" will be whatever it was before the with-block - no exception will ever be caught by the except-clause Generally speaking, no exception that a context manager handles (i.e. suppresses) will ever be available to be caught. -- ~Ethan~

On 4/8/21 1:21 PM, Chris Angelico wrote:

On Fri, Apr 9, 2021 at 6:16 AM Ethan Furman wrote:

...

On 4/8/21 11:25 AM, Chris Angelico wrote:

...

...

Similar question: What would be the semantics of this?

with contextlib.suppress(BaseException): a = b / c except BaseException as e: print(e)

What types of exception could be caught and what types couldn't?

Well, if every exception is derived from BaseException (they are) and contextlib.suppress(BaseException) suppresses all BaseException-derived exceptions (it does) then the semantics of the above are:

- "a" will be the result of "b / c" if no exception occurs - otherwise, "a" will be whatever it was before the with-block - no exception will ever be caught by the except-clause

Generally speaking, no exception that a context manager handles (i.e. suppresses) will ever be available to be caught.

What about NameError looking up contextlib, or AttributeError looking up suppress? Will they be caught by that except clause, or not?

Ah, good point -- those two would get caught, as they happen before contextlib.suppress() gets control.

Thank you for making my point: your assumption is completely the opposite of the OP's, given the same syntactic structure.

The guidance should be: `try with` behaves exactly as `try/except with a with`, meaning that NameError and AttributeError for those two reasons would still be caught. Yes, it's easy to miss that at first glance, but it's just as easy to miss in the traditional try/except layout: ```python try: with contextlib.suppress(BaseException): # do stuff except BaseException as e: print(e) ``` How many people are going to look at that and think, "oh, NameError and AttributeError can still be caught" ? -- ~Ethan~

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~

On 2021-04-08 11:25, Chris Angelico wrote:

On Fri, Apr 9, 2021 at 2:24 AM Paul Bryan wrote:

...

Q. Safe to assume this would catch exceptions from both the call to `open` as well as the call to `open.__enter__`?

No, not safe to assume. It's equally reasonable to define it as guarding only the body of the statement, or as guarding the header as well. The semantics have to be locked in one way or the other, and half the time that's going to be incorrect.

Hmm, I don't see the problem. I'd assume/want it to catch everything not already caught by the context manager. The scope would be everything inside the "try-with..." and not be mandatory of course. That's why the original example "try ..." comes first and is on the outside. If you wanted it to guard only *inside* the with statement, then you'd not be putting the try on the outside in the first place. You'd put it inside. I've used try-with many, many times, and can't currently remember any instances of with-try. -Mike

My application-level

exception handling is rarely that close to the file operations, it's usually at a much higher level.

With is used for lots of other things, too. Does this same point apply to other use cases? For my part, I still find the extra indentation annoying required for with to work with files, even without a try block around it. :-( -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

But if there are two proposals with conflicting semantics for the same syntax that kills both ideas, doesn’t it? Because apparently it’s not clear what the syntax should mean. On Fri, Apr 9, 2021 at 00:28 Serhiy Storchaka wrote:

08.04.21 17:59, anthony.flury via Python-ideas пише:

...

I was wondering whether a worthwhile extension might be to allow the `with` statement to have an `except` and `else` clauses which would have the same semantics as wrapping the `with` block with a try - for example the above would now look like:

with open('config.cfg', 'r') as cfg: # Process the open file config = load_config(cfg) except FileNotFound: logging.info('Config file not found - using default configuration') except PermissionError: logging.warning('Cannot open config .cfg - using default configuration') config = default_config() else: logging.info('Using config from config.cfg')

A year or two ago I proposed the same syntax with different semantic: to catch only exceptions in the context manager, not in the with block. Exceptions in the with block you can catch by adding try/except around the with block, exceptions in the with block and the context manager you can catch by adding try/except around the with statement, but there is no currently way to catch only exceptions in the context manager.

It is quite a common problem, I encounter it several times per year since then. I still have a hope to add this feature, and it will conflict with your idea.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/OMAEC4... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile)

On 4/9/21 11:33 AM, anthony.flury via Python-ideas wrote:

On 09/04/2021 19:02, Guido van Rossum wrote:

...

But if there are two proposals with conflicting semantics for the same syntax that kills both ideas, doesn’t it? Because apparently it’s not clear what the syntax should mean.

Surely it depends (if we adopt a proposal) how we document it. You could argue that very few syntax elements are entirely clear unless we explain it - which is what the point of the documentation.

For example for someone who doesn't know what 'with' does, it isn't necessarily clear (just from the syntax) that 'with' ensures finalizing of resources when an exception occurs - the documentation has to explain that.

Especially if one is coming from, say, Foxpro, where `with` is a shortcut for omitting the class name for attribute lookups. -- ~Ethan~

Serhiy Storchaka writes:

A year or two ago I proposed the same syntax with different semantic: to catch only exceptions in the context manager, not in the with block.

FWIW, this is the semantics I would expect, for the reason you give:

Exceptions in the with block you can catch by adding try/except around the with block, exceptions in the with block and the context manager you can catch by adding try/except around the with statement, but there is no currently way to catch only exceptions in the context manager.

Does this apply to the necessary setup in any other syntactic constructs? For example, in the abstract this is a "problem" in 'for':

...

...

for i in [1]: ... for j in 2: ... pass ... Traceback (most recent call last): File "<stdin>", line 2, in <module> TypeError: 'int' object is not iterable

it's not possible to catch the TypeError *only* in the outer loop. Of course this isn't a "real" problem in 'for', since this TypeError is surely not an exceptional situation you need to catch and handle at runtime, it's just a bug. I guess the biggest difference is that in 'with' the setup (corresponding to calling 'iter' on the iterable in 'for') is specified to be arbitrary code and can be arbitrarily complex. 'with' is the only construct where that's true, that I know of. (Of course the setups for other syntactic constructs are very simple.) Is that so? Steve