On Sat, Feb 08, 2020 at 10:07:27AM +1100, Steven D'Aprano wrote:
> 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
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
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
On Fri, 7 Feb 2020 at 23:14, Steven D'Aprano wrote:
> 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.
On Fri, 7 Feb 2020 20:08:35 -0800
Andrew Barnert 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.
> >
>
> I interpreted
> 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
On Fri, Feb 07, 2020 at 09:57:18AM -0800, Andrew Barnert via Python-ideas wrote:
> 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
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
On Fri, Feb 07, 2020 at 04:28:53PM +0200, Ram Rachum wrote:
> 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
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
My reaction to this whole discussion is to question whether it's
worth having two different forms of exception chaining in the first
place. It seems to be a subtle distinction that most programmers
either aren't aware of or can't be bothered making when they write
a 'raise' statement.
I'm not
On Feb 7, 2020, at 12:43, Ram Rachum wrote:
>
> I would like to raise a sort-of ultimatum to everyone in this thread.
Is that a raise from Django or a raise as? :)
> As far as I know, the `raise foo from bar` syntax, and the distinction
> between the two exception-chaining messages, didn't
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
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.
On Fri, Feb 7, 2020 at 11:00 PM Soni L. wrote:
>
>
> On 2020-02-07 5:38 p.m., Ram Rachum wrote:
> > I would like to raise a sort-of
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
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
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
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 =
On Fri, Feb 7, 2020 at 7:56 AM Ethan Furman wrote:
> 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:
>
> 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
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
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
> 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:
On 02/07/2020 09:06 AM, Anders Hovmöller wrote:
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
> 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
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.
--
~Ethan~
Aside: please trim the parts of your
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:
If the only difference is the text between the stack traces, why aren't you
suggesting to change that text?
> On 7 Feb 2020, at 15:30, Ram Rachum wrote:
>
>
> Hi,
>
> I'd like to suggest an idea, that builds on PEPs 3134 and 409.
>
> This idea came up when discussing a problem on the
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
29 matches
Mail list logo
