On 02/07/2020 07:33 AM, Serhiy Storchaka wrote:

07.02.20 16:28, Ram Rachum пише:

...

The idea is to add `raise as` syntax, that raises an exception while setting the currently caught exception to be the cause. It'll look like this:

     try:          1/0      except ZeroDivisionError:          raise as ValueError('Whatever')

What it does is a shorter version of this:

     try:          1/0      except ZeroDivisionError as error:          raise ValueError('Whatever') from error

How does it differ from

    try:         1/0     except ZeroDivisionError:         raise ValueError('Whatever')

Here's a diff: $ diff no_from.py with_from.py 3,4c3,4 - ... except ZeroDivisionError: - ... raise ValueError('Whatever') --- + ... except ZeroDivisionError as e: + ... raise ValueError('Whatever') from e 10c10 - During handling of the above exception, another exception occurred: --- + The above exception was the direct cause of the following exception: To me the difference between "raise from" and "raise" is the implicit meaning: - "During handling of ..." implies that the second exception should not have occurred and there is a bug in the exception handling code - "The above exception ..." implies that this code path is normal and extra information is being supplied Personally, my main use of "raise from" is "raise from None". I'm -1 on the new syntax: to me it looks much more like a "raise ... from None". -- ~Ethan~

On Sat, Feb 8, 2020 at 4:51 AM Shai Berger wrote:

To summarize, I am suggesting that

except ExceptionType: raise as OtherException(...)

Have, more-or-less, the semantics of Python 2's:

except ExceptionType: traceback = sys.exc_info()[2] raise OtherException, OtherException(...), traceback

-1. That would mean that a line of code could phantom-raise an exception that it has no idea even exists. I'd much rather it be defined with semantics based on existing exception chaining (which is what Ram's original proposal was). ChrisA

On 2020-02-07 5:38 p.m., Ram Rachum wrote:

I would like to raise a sort-of ultimatum to everyone in this thread.

As far as I know, the `raise foo from bar` syntax, and the distinction between the two exception-chaining messages, didn't really catch on. I know about them, like them and use them, but most Python developers and open-source packages don't.

If I understand correctly, the `raise from` syntax was introduced in Python 3.0, so in 2008. It's been with us for 12 years. We finally made the transition to Python 3, and I feel that most Python developers I interact with are using Python 3. But the `raise from` syntax is something that's still considered esoteric.

My point is that so far, its adoption was a failure.

If we have any hopes that its adoption will be a success, we should think, what is our plan for its success? Here are a few options:

1. Keep waiting a few more years and see whether people will spontaneously feel like starting to use it. 2. Accept the fact that it's a failed feature that would never get adopted. 3. Start an effort to transition to `raise from` in appropriate cases in high-profile Python projects such as Django, hoping it'll trickle down from there to the wider public. 4. Figure out why people don't use `raise from`, and find solutions to these problems. If the Django maintainers don't use it because it's too verbose, introduce less verbose way. Even if it takes 6 years to get into Django because of the release delay, it's worth to start working on it now. 5. Accept the fact that Django isn't the beacon of Pythonic-ness that many of us see it as, and maybe it can stay behind in this regard while other, newer projects are adopting more Pythonic practices.

Any other options?

I'm gonna make a wild suggestion: An explicit "raise" in an "except" body gets rewritten as "raise from" the parent exception. Hopefully this doesn't break anything, but, who knows. This means you get: except Foo as e:   raise Bar # raises Bar, because of Foo, as if by "raise Bar from e" except Foo as e:   my_raise(Bar) # raises Bar while handling Foo, as it currently stands.

On 2020-02-07 6:05 p.m., Ram Rachum wrote:

Hi Soni,

I think that your suggestion is identical to Shai's. It would be good, but unfortunately it has the 3 problems I raised in my email from an hour ago. of which 2 and 3 are personal opinions.

(for 2: you can just use a function. I'd consider that "explicit syntax" tbh.) my point is tho: if your code implicitly raises during exception handling, that's likely a bug in your code. if it explicitly raises instead, that's likely intended instead. having the language reflect that would be useful IMO regardless of backwards compatibility concerns.

I'm gonna make a wild suggestion:

An explicit "raise" in an "except" body gets rewritten as "raise from" the parent exception.

Hopefully this doesn't break anything, but, who knows. This means you get:

except Foo as e:    raise Bar # raises Bar, because of Foo, as if by "raise Bar from e"

except Foo as e:    my_raise(Bar) # raises Bar while handling Foo, as it currently stands. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org mailto:python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org mailto: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/XN7B2Z... Code of Conduct: http://python.org/psf/codeofconduct/

On Sat, Feb 08, 2020 at 11:29:00AM +1300, Greg Ewing wrote:

So my proposal would be to merge the two kinds of chaining into one, and use wording in the traceback that is neutral as to the relationship between the two exceptions.

-1 There's no harm in the current wording. If very few people care about the difference, that's fine. Let the minority who do care continue to care, and the majority will continue to treat both wordings as boilerplate that they don't even bother to read. In my strong opinion, there's no need to change anything. -- Steven

On Fri, Feb 07, 2020 at 10:38:42PM +0200, Ram Rachum wrote:

As far as I know, the `raise foo from bar` syntax, and the distinction between the two exception-chaining messages, didn't really catch on. I know about them, like them and use them, but most Python developers and open-source packages don't. [...] My point is that so far, its adoption was a failure.

Failure judged according to what standard? If a feature isn't used a lot, does that make it a failure? Personally, I use "from None" quite a lot, so to me that's a rather big success.

If we have any hopes that its adoption will be a success, we should think, what is our plan for its success? Here are a few options:

You missed the most important: Do nothing. Accept that "raise from error" offers little advantage over plain old "raise", and if the majority of people can't be bothered using it, don't stress over the microscopic difference in meaning between the default message "During handling of the above exception" and the "above exception was the direct cause..." message you get from explicitly setting the cause with "from error". YMMV and this is just my opinion, but personally I think that exception chaining is rarely useful even at the best of times. For me, the only time I care about "raise from" is to suppress exception chaining by setting the cause to None. If you disagree and want to chain your exceptions, please go right ahead doing what you are doing. -- Steven

On Sat, Feb 8, 2020 at 12:27 PM Paul Moore wrote:

So I'd be hesitant about calling exception chaining a failure (like the OP, not Steven, did) for a while yet. And even then, I would't call it a failure, just a relatively niche feature that is helpful in some uncommon cases.

I didn't call exception chaining a failure. What is currently a failure is the "raise foo from bar" syntax, and the accompanying difference between "Direct cause of" and "During handling of". I love this feature and I want it to succeed. The thing is, it's not enough for some packages to use "raise foo from bar", while others (like Django) don't. Most Python developers don't know about this difference between "During the handling of" and "The above exception was the direct cause", because "raise foo from bar" isn't that prevalent yet. This is a chicken-and-egg problem, because as long as project maintainers don't use "raise foo from bar", the exception chaining wouldn't show the correct text, and people would get used to the fact that they can't rely on this text to be correct. Like any chicken-and-egg problem of changing people's habits, the best we could hope is to move it forward at a glacial pace-- A situation somewhat similar to the move to Python 3. Thanks, Ram.

On Fri, Feb 7, 2020 at 7:47 PM Shai Berger wrote:

Hi,

In the Django thread, I suggested that an implicit "raise from" should be the behavior whenever an exception is raised directly in exception-handling code (that is, within an except: or finally: clause). Ram claimed there were problems with that, but gave no details; I would be happy to know what these problems are.

1. Backward compatibility. The meaning of existing plain raises would change, and if irresponsible people depended on it, we'd now break their assumptions. It's annoying and unlikely, but as far as I know python-dev is conservative regarding backward compatibility for esoteric cases. (Remember the non-Ascii Windows version strings? ;) 2. You would then need an explicit way to raise inside an except clause while stating the previous exception wasn't a cause. The syntax `from None` is already taken as "suppress the previous exception", so you'd need to introduce new syntax for that too. 3. The fact that `raise foo` inside `except` means something different than `raise foo` in a function that is called by code inside except, is something that might seem dissonant to many people, myself included. There might be more problems, I don't know.

The main problem I see with "raise from None" is that it removes the inner part of the traceback. It expresses the idea that everything that happened in lower levels is not really interesting -- you should have all the information for handling or debugging the problem by considering the flow from here up. I think in most cases where you'd want to change the type and/or value of an excpetion, this is unrealistic.

Yeah, I feel the same. I can think of very few good places where `raise foo from None` is beneficial. God, all the times I was desperately troubleshooting a problem, hunting for any glimpse of information of what happened, like looking for drinkable water in a desert... I'd never want to have a traceback excluded, ever.

With respect to Ram's current suggestion, I think that for it to really make a difference, the "raise as" should not be thought of as a shorthand/variant of "raise ... from", but rather as a variant of bare raise; that is, it should not create a chained exception, but an effect of re-raising while changing the exception value (and potentially type). This, I think, would address Ethan's claim that "this should really be raise from None", without the cons described earlier; it is a better expression of the idea "I just want to change the exception being raised".

To summarize, I am suggesting that

except ExceptionType: raise as OtherException(...)

Have, more-or-less, the semantics of Python 2's:

except ExceptionType: traceback = sys.exc_info()[2] raise OtherException, OtherException(...), traceback

This is very interesting. Took me a few reads to understand what you mean, that's an ingenious idea. It's true that the traceback for the new exception would likely be useless and should be thrown away, if it's just one stack level with no information. However, it is quite a bit of magic, and that's a disadvantage. People don't generally have the expectation that a raise in one location would show a traceback for another location. They might think the lines under the except weren't called, when they were. I wouldn't want it for this reason.

On 7 Feb 2020, at 16:59, Ethan Furman wrote:

On 02/07/2020 07:44 AM, Anders Hovmöller wrote:

...

If the only difference is the text between the stack traces, why aren't you suggesting to change that text?

Because the text is important in what it implies. See my other message for details.

Sorry but I still don't understand. I agree the difference in text is a vast improvement. But I don't understand why the implicit case should have the bad text. Is that text actually better ever? / Anders

On Feb 7, 2020, at 07:47, Anders Hovmöller wrote: If the only difference is the text between the stack traces, why aren't you suggesting to change that text?

I think in the case where the exception handler code has an error in handling the exception (e.g., you try to log to a closed file), the existing text is exactly right, and the text used in the explicit chaining case would be misleading. However, Shai Berger had an interesting idea in that Django thread: treat a `raise` directly under an `except` block special. For example: except ZeroDivisionError: raise ValueError('whatever') # would produce a chaining error message except ZeroDivisionError: log(closedfile, “whatever”) # would produce an another error during handling error message except ZeroDivisionError: MyFancyError(stuff).throwme() # would produce error during handling like the log case # unless the author of throwme decides they want otherwise # in which case they just have to check and raise from I’m not sure if “special” should mean that it’s treated identical to a raise from (as Shai suggested), as that might cause backward compat issues? I haven’t thought it through. Alternatively, if we just stash a new flag somewhere that the traceback machinery can find, we could get the same behavior (or even a third distinct connecting string) without any such issues, at the cost of more complexity. There might be other problems I’m not seeing here. But it seems at least worth exploring.

On Feb 7, 2020, at 16:11, Steven D'Aprano wrote:

Shai Berger wants to set it implicily, based on where the raise is. If it is "directly" under the except line, implicitly set the cause.

It seems like a truly bad idea to change the semantics of the exception depending on which of these I happen to write:

# exception with __cause__ magically set except ZeroDivisionError: raise ValueError(generate_long_exception_text())

# exception with __context__ set but not __cause__ except ZeroDivisionError: msg = generate_long_exception_text() raise ValueError(msg)

I interpreted “directly under” as meaning “directly lexically contained by”, not “on the next physical line”. And even if that isn’t what Shai meant, it’s what I meant. :) So both of these are the same case. The different case is where you call some function (or use some operator or syntax) that raises, instead of using a raise statement. Which I thought would have been obvious from the examples, but I guess not, so… now hopefully it’s clear? The idea is that when you explicitly raise, that’s probably because you wanted to raise, and that’s obvious to anyone reading your code, but when you called log and it happened to raise because you’re shutting down and the log file no longer exists, that’s probably an error. I’m not sure it is worth distinguishing these cases in the first place, but if it is, I think Shai’s idea (or mine, if I misinterpreted Shai’s) might be a decent match, and very simple.

On 2/7/2020 11:08 PM, Andrew Barnert via Python-ideas wrote:

...

On Feb 7, 2020, at 16:11, Steven D'Aprano wrote:

Shai Berger wants to set it implicily, based on where the raise is. If it is "directly" under the except line, implicitly set the cause.

It seems like a truly bad idea to change the semantics of the exception depending on which of these I happen to write:

# exception with __cause__ magically set except ZeroDivisionError: raise ValueError(generate_long_exception_text())

# exception with __context__ set but not __cause__ except ZeroDivisionError: msg = generate_long_exception_text() raise ValueError(msg) I interpreted “directly under” as meaning “directly lexically contained by”, not “on the next physical line”. And even if that isn’t what Shai meant, it’s what I meant. :)

So both of these are the same case. The different case is where you call some function (or use some operator or syntax) that raises, instead of using a raise statement. Which I thought would have been obvious from the examples, but I guess not, so… now hopefully it’s clear?

The idea is that when you explicitly raise, that’s probably because you wanted to raise, and that’s obvious to anyone reading your code, but when you called log and it happened to raise because you’re shutting down and the log file no longer exists, that’s probably an error.

I’m not sure it is worth distinguishing these cases in the first place, but if it is, I think Shai’s idea (or mine, if I misinterpreted Shai’s) might be a decent match, and very simple.

I'm -1 on this for several reasons, but the biggest is that if you refactored the code to call a function to handle the exception, you'll change the exception chaining. Erc

Even apart from the long time delay, it seems clear that the Django developers rejected 'raise from' for design reasons. That might be right or wrong as a decision, but it's a separate project from Python itself. Nothing in the issue even hints that they would have accepted it *if only* the spelling were a few characters shorter. On Fri, Feb 7, 2020, 12:43 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On Feb 7, 2020, at 06:32, Ram Rachum wrote:

It's possible that introducing the simpler `raise as` would increase adoption and make users pay attention to the message between exception tracebacks.

From the Django thread that you linked, when you asked whether they’d use it, the reply was:

Maybe... it's still more verbose for no gain as I see it.

I think the default implicit chaining is correct in the default case. It's only if you want to adjust that (or suppress is with `from None`) that the extra clause comes in handy. I think using the default unless there's a reason not to is, in general, a good policy.

And everyone else commenting on the thread seems to be agreeing with Carlton.

So it sounds like they’re probably not going to use the new syntax even if you get this feature into Python. And that raises the question of who _would_ use it. If this syntax is needed anywhere, it’s in a deep framework that puts multiple levels of wrapping around complex things; Django seems like the ideal use for it if anything is.

And of course even if you did convince them, they wouldn’t start using it for Django 3.0 or 3.1, which have to run on Python 3.6+ and can’t suddenly start requiring a version of Python that’s not even in alpha yet. It looks like it would probably be about 3 years after Python 3.9 or 3.10 (or whenever you get this feature in) before you could change the next minor Django version after that. (Unless you can convince them that this new feature is not only worth using, but so compelling that it’s worth being much more aggressive than usual in requiring the latest Python, which doesn’t seem all that likely.)

_______________________________________________ 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/S7JHJF... Code of Conduct: http://python.org/psf/codeofconduct/