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.
On Fri, Feb 7, 2020 at 11:00 PM Soni L. firstname.lastname@example.org wrote:
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:
- 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. _______________________________________________ Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/XN7B2Z... Code of Conduct: http://python.org/psf/codeofconduct/