Mailman 3 Revert #12085 fix for __del__ attribute error message - Python-Dev

Revert #12085 fix for del attribute error message

older
Re: [Python-Dev] cpython: Don't...

Terry Reedy

21 Sep 2013 21 Sep '13

9:16 p.m.

When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example:

...

...
...
class C(): def __del__(self): raise AttributeError

...

...
...
c=C() del c Exception AttributeError: AttributeError() in > ignored

The AttributeError is ignored, I presume, because one may be expected if __new__ runs but __init__ does not, because of an exception. AttributeErrors can also be expected during exit cleanup. The message seems not to be a Warning. So it seems that is cannot be suppressed. The OP of http://bugs.python.org/issue12085 encountered this message with an unnecessary use of subprocesses.Popen. (There is better code that avoids the problem.) He considered the message a problem as it interfered with his output. He suggested the fix of changing 'self.attr' to "getattr(self. 'attr', False)". Viktor Stinner applied this fix. I believe it should be reverted for three reasons: 1. It results in TypeError on exit when gettattr is set to None before __delete__ is called. http://bugs.python.org/issue19021. Even is that is fixed with an alternate patch (creating a 'backup' class attribute), I think it would still be wrong. 2. If we do not agree with the OP that putting output on stderr is bad, then no fix is needed and there should be none. 3. If we do agree that the unconditional output is a problem, then there should be a general fix. It is, in a sense, just happenstance that the OP encountered this with Popen. Some possibilities: a. Decide the the message is not needed; just silently ignore the __del__ AttributeError. I am not sure what its intended use is. b. Make the message a Warning that can be blocked, perhaps a RuntimeWarning. Does this warning message predate the warnings module, new in 2.1? c. If the __del__ AttributeError occurs while processing the __init__ error, just chain it normally. But this would, I presume interfere with catching the __init__ exception. d. Add a missing attribute in cleanup message to end of the __init__ exception message. -- Terry Jan Reedy

Show replies by date

R. David Murray

21 Sep 21 Sep

10:15 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy wrote:

...

When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example:

...
...
...
class C(): def __del__(self): raise AttributeError

...
...
...
c=C() del c Exception AttributeError: AttributeError() in > ignored

...

From the issue, it sounds like it could be considered either (or most

This is a replacement for a traceback. In later Python versions, the full traceback is printed. In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), but not all of them do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case). So the question is, is the bug in the user code, or the stdlib code? likely, both). --David

Terry Reedy

11:55 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/21/2013 6:15 PM, R. David Murray wrote:

...

On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy wrote:

...
When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example:

...
...
...
class C(): def __del__(self): raise AttributeError

...
...
...
c=C() del c Exception AttributeError: AttributeError() in > ignored

This is a replacement for a traceback. In later Python versions, the full traceback is printed.

The above is 3.3.2. In 3.4.0a2, the traceback of the ignored exception is indeed printed. Exception ignored in: > Traceback (most recent call last): File "", line 2, in __del__ AttributeError:

...

In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021),

Lets call that a buglet ;-). Not really harmful, but annoying. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? This would be a separate issue from #12085.

...

but not all of them do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case).

Which is why the message should be printed, so the developer can decide. -- Terry Jan Reedy

Guido van Rossum

22 Sep 22 Sep

2:30 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. Also, IMO writing to stderr is fair game -- reporting errors is what it is for. As to making them warnings, I don't know that the warnings machinery is easily adaptable for this purpose. Warnings can be suppressed but they can also be turned into full exceptions; the latter doesn't really apply here (see previous paragraph). But I would not object if someone found a way to do this, though I'd prefer the default behavior to remain what it is in 3.4 (print a full traceback). On Sat, Sep 21, 2013 at 4:55 PM, Terry Reedy wrote:

...

On 9/21/2013 6:15 PM, R. David Murray wrote:

...
On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy wrote:

...
When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example:

...
...
...
class C(): def __del__(self): raise AttributeError

...
...
...
c=C() del c Exception AttributeError: AttributeError() in > ignored

This is a replacement for a traceback. In later Python versions, the full traceback is printed.

The above is 3.3.2. In 3.4.0a2, the traceback of the ignored exception is indeed printed.

Exception ignored in: > Traceback (most recent call last): File "", line 2, in __del__ AttributeError:

In the general case it represents a bug in

...
the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021),

Lets call that a buglet ;-). Not really harmful, but annoying. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it?

This would be a separate issue from #12085.

...
but not all of them

...
do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case).

Which is why the message should be printed, so the developer can decide.

-- Terry Jan Reedy

______________________________**_________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/**mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/**mailman/options/python-dev/** guido%40python.orghttps://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

Terry Reedy

5:35 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/21/2013 10:30 PM, Guido van Rossum wrote:

...

Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value.

That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)?

...

Also, IMO writing to stderr is fair game -- reporting errors is what it is for.

So developers who really want to control all screen output should redirect or capture it somehow.

...

As to making them warnings, I don't know that the warnings machinery is easily adaptable for this purpose. Warnings can be suppressed but they can also be turned into full exceptions; the latter doesn't really apply here (see previous paragraph). But I would not object if someone found a way to do this, though I'd prefer the default behavior to remain what it is in 3.4 (print a full traceback).

Antoine and Georg think it a dubious idea, so I will not pursue it. Developers who encounter messages from the stdlib can report and wait for a fix. -- Terry Jan Reedy

Guido van Rossum

6:41 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy wrote:

...

On 9/21/2013 10:30 PM, Guido van Rossum wrote:

...
Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value.

That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)?

That's a good point, although I'm not sure 'skipped' is better. Maybe use a more neutral verb like 'occurred'? -- --Guido van Rossum (python.org/~guido)

Terry Reedy

8:37 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/22/2013 2:41 PM, Guido van Rossum wrote:

...

On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy mailto:tjreedy@udel.edu> wrote:

On 9/21/2013 10:30 PM, Guido van Rossum wrote:

Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value.

That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)?

That's a good point, although I'm not sure 'skipped' is better.

Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it.

...

Maybe use a more neutral verb like 'occurred'?

"Exception occurred in ..." is even better at say what happened. I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like "Although caught internally, it still indicates a problem." Otherwise, when no other output follows, as in ...

...

del c Exception ocurred in: ", line 2, in __del__ AttributeError:

...
...
It may not be completely obvious to a non-expert that the traceback is not a 'real' traceback from an exception that was allowed to propagate, and that it did not stop execution and cannot be caught.

-- Terry Jan Reedy

Nick Coghlan

23 Sep 23 Sep

3:24 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 23 Sep 2013 06:38, "Terry Reedy" wrote:

...

On 9/22/2013 2:41 PM, Guido van Rossum wrote:

...
On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy mailto:tjreedy@udel.edu> wrote:

On 9/21/2013 10:30 PM, Guido van Rossum wrote:

Exceptions in __del__ point to bugs (sometimes in the stdlib)

that

...

...
should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value.

That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)?

That's a good point, although I'm not sure 'skipped' is better.

Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it.

...
Maybe use a more neutral verb like 'occurred'?

"Exception occurred in ..." is even better at say what happened.

I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like "Although caught internally, it still indicates a problem."

Brevity is still a virtue. The relevant C API function is called "PyErr_WriteUnraisable", so just starting the message as something like "Unraisable exception suppressed in..." might work. Cheers, Nick.

...

Otherwise, when no other output follows, as in ...

...
del c Exception ocurred in:
Traceback (most recent call last): File "", line 2, in __del__ AttributeError:

...
...
...
It may not be completely obvious to a non-expert that the traceback is

not a 'real' traceback from an exception that was allowed to propagate, and that it did not stop execution and cannot be caught.

...

-- Terry Jan Reedy

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Ethan Furman

4:06 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 09/22/2013 08:24 PM, Nick Coghlan wrote:

...

On 23 Sep 2013 06:38, "Terry Reedy" mailto:tjreedy@udel.edu> wrote:

...
On 9/22/2013 2:41 PM, Guido van Rossum wrote:

...
On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy mailto:tjreedy@udel.edu mailto:tjreedy@udel.edu>> wrote:

On 9/21/2013 10:30 PM, Guido van Rossum wrote:

Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value.

That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)?

That's a good point, although I'm not sure 'skipped' is better.

Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it.

...
Maybe use a more neutral verb like 'occurred'?

"Exception occurred in ..." is even better at say what happened.

I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like "Although caught internally, it still indicates a problem."

Brevity is still a virtue. The relevant C API function is called "PyErr_WriteUnraisable", so just starting the message as something like "Unraisable exception suppressed in..." might work.

I like that! +1 -- ~Ethan~

Guido van Rossum

4:29 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Sunday, September 22, 2013, Nick Coghlan wrote:

...

Brevity is still a virtue. The relevant C API function is called "PyErr_WriteUnraisable", so just starting the message as something like "Unraisable exception suppressed in..." might work.

Somehow "unraisable" sounds too technical, and "suppressed" is hardly right given that it is printed... Let's leave well enough alone. --Guido -- --Guido van Rossum (on iPad)

Glenn Linderman

5:28 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/22/2013 9:29 PM, Guido van Rossum wrote:

...

On Sunday, September 22, 2013, Nick Coghlan wrote:

Brevity is still a virtue. The relevant C API function is called "PyErr_WriteUnraisable", so just starting the message as something like "Unraisable exception suppressed in..." might work.

Somehow "unraisable" sounds too technical, and "suppressed" is hardly right given that it is printed...

Let's leave well enough alone.

"printable-only exception in..."

Greg Ewing

6:11 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Guido van Rossum wrote:

...

Somehow "unraisable" sounds too technical,

It's not even really accurate. It's been raised, it just can't be propagated any further. But "unpropagatable exception" would be a bit of a mouthful. -- Greg

Nick Coghlan

8:17 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 23 September 2013 16:11, Greg Ewing wrote:

...

Guido van Rossum wrote:

...
Somehow "unraisable" sounds too technical,

It's not even really accurate. It's been raised, it just can't be propagated any further. But "unpropagatable exception" would be a bit of a mouthful.

I felt I needed a reminder of the context where this string gets printed, so I created this toy example:

...

...
...
class C: ... def __del__(self): ... raise RuntimeError("Going away now") ... x = C() del x Exception ignored in: > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Here's what I suggest changing that error to:

...

...
...
del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

First and foremost, "Unraisable exception suppressed" should be quite search engine friendly. The only current hits for that are on archived versions of this thread, whereas the existing "Exception ignored" sends you down a rabbit hole of Stack Overflow answers related to broken pipe handling. If we create a new FAQ entry for "What does 'Exception ignored' or 'Unraisable exception suppressed' mean?" when making the change for 3.4, then that will definitely help 3.4 users and may eventually help users of other versions as well :) Secondly, it concisely explains exactly what is going on, so developers that look it up once should be able to remember the meaning in the future: - the given exception was suppressed (*what* happened) - it was suppressed because Python couldn't raise it any further (*why* it happened) I think it's OK for the terms to be a little technical and arcane because problems relating to broken finalizers and failures during interpreter startup and shutdown *are* a little arcane. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Antoine Pitrou

8:45 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...

Here's what I suggest changing that error to:

...
...
...
del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ? Regards Antoine.

Nick Coghlan

8:51 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 23 September 2013 18:45, Antoine Pitrou wrote:

...

Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
...
...
del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it) "Suppressed" also says more than "caught" does, since "caught and reraised the exception" makes sense, while "suppressed and reraised the exception" contradicts itself. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Antoine Pitrou

3:22 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...

On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
...
...
del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). Regards Antoine.

R. David Murray

4:23 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 17:22:45 +0200, Antoine Pitrou wrote:

...

On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...
On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
...
> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

Would it work to say "Asynchronous exception suppressed..."? It's not-entirely-precise, but it's less imprecise than "unraisable". --David

Terry Reedy

6:27 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/23/2013 12:23 PM, R. David Murray wrote:

...

On Mon, 23 Sep 2013 17:22:45 +0200, Antoine Pitrou wrote:

...
On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...
On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
>> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

Would it work to say "Asynchronous exception suppressed..."? It's not-entirely-precise,

As in the example above ('del x').

...

but it's less imprecise than "unraisable".

How 'troublesome'? That is always accurate, as proven by this thread. We really need an "Understanding Exceptions" HOWTO, and I expect we will get one. So I agree with Nick that something easily searched would be good. -- Terry Jan Reedy

Nick Coghlan

9:19 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 Sep 2013 01:24, "Antoine Pitrou" wrote:

...

On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...
On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
...
> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr". Cheers, Nick.

...

Regards

Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Ethan Furman

9:26 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:19 PM, Nick Coghlan wrote:

...

The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr".

Wow. How many legs does that HumptyCamel have, anyway? ;) -- ~Ethan~

Antoine Pitrou

9:35 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote:

...

On 24 Sep 2013 01:24, "Antoine Pitrou" wrote:

...
On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...
On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

...
>> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*.

But that's because you already know what it's supposed to convey. The average user doesn't, and only sees "unraisable".

...

The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr".

"PyErr_WriteUnraisable" is right at the point where it used: I can't raise that exception at this point, therefore I call PyErr_WriteUnraisable. However, from the point of view of the user reading the traceback, the exception *was* raised. Regards Antoine.

Ethan Furman

9:38 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:35 PM, Antoine Pitrou wrote:

...

On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote:

...
On 24 Sep 2013 01:24, "Antoine Pitrou" wrote:

...
On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote:

...
On 23 September 2013 18:45, Antoine Pitrou wrote:

...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit :

...
Here's what I suggest changing that error to:

>>> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*.

But that's because you already know what it's supposed to convey. The average user doesn't, and only sees "unraisable".

All the more reason to have text in the error message that is easily searchable. -- ~Ethan~

Antoine Pitrou

10:29 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman wrote:

...

...
But that's because you already know what it's supposed to convey. The average user doesn't, and only sees "unraisable".

All the more reason to have text in the error message that is easily searchable.

Then I propose "CA6yuaYV6dygPfJRxUrhtg". It should be easily searchable ;-) Seriously, "easily searchable" is a rather weak criterion for an error message. It should be easily understandable and non-misleading first. Regards Antoine.

Nick Coghlan

24 Sep 24 Sep

7:25 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 September 2013 08:29, Antoine Pitrou wrote:

...

On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman wrote:

...
...
But that's because you already know what it's supposed to convey. The average user doesn't, and only sees "unraisable".

All the more reason to have text in the error message that is easily searchable.

Then I propose "CA6yuaYV6dygPfJRxUrhtg". It should be easily searchable ;-)

Seriously, "easily searchable" is a rather weak criterion for an error message. It should be easily understandable and non-misleading first.

You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: - there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead *without users needing to do any research*. A verbose wording is no good either, as that degenerates into a wall of text that people will *still* have to extract pieces from to plug into a search engine to figure out what they mean. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Nick Coghlan

7:32 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 September 2013 17:25, Nick Coghlan wrote:

...

Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

- there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead

*without users needing to do any research*.

Oops, reworded the second part of that sentence without fixing the first part. It should have said: ============== It doesn't make sense to prefer the status quo because you're holding out a forlorn hope for a concise wording that explains: - there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead *without users needing to do any research*. ============== Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Antoine Pitrou

7:34 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan wrote:

...

You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it.

Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel.

"Unraisable" is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning. If you want something that people won't understand, you can use something like "asynchronous exception".

...

Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

I've proposed other options. Regards Antoine.

Nick Coghlan

8:06 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 September 2013 17:34, Antoine Pitrou wrote:

...

On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan wrote:

...
You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it.

Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel.

"Unraisable" is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning.

How is it wrong? At the point where the interpreter says "This exception is now unraisable", what, precisely, is it saying that is wrong? It isn't saying "this has never been raised". It is saying, "where it is currently being processed, this exception cannot be raised".

...

If you want something that people won't understand, you can use something like "asynchronous exception".

Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread.

...

...
Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

I've proposed other options.

"Automatically caught" says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Antoine Pitrou

8:16 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 18:06:15 +1000 Nick Coghlan wrote:

...

How is it wrong? At the point where the interpreter says "This exception is now unraisable", what, precisely, is it saying that is wrong? It isn't saying "this has never been raised". It is saying, "where it is currently being processed, this exception cannot be raised".

Well, it is saying it. If it's conceptually unraisable, it can't be raised. I know your point is that it is only unraisable *now*, but that's not the intuitive interpretation.

...

...
...
Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

I've proposed other options.

"Automatically caught" says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr.

I would say they are manually caught by except clauses (user code == manual intervention), and automatically caught when "silenced" or "unraised" by the interpreter. Regards Antoine.

Jan Kaliszewski

1:53 p.m.

24.09.2013 10:16, Antoine Pitrou wrote:

...

On Tue, 24 Sep 2013 18:06:15 +1000 Nick Coghlan wrote:

...
How is it wrong? At the point where the interpreter says "This exception is now unraisable", what, precisely, is it saying that is wrong? It isn't saying "this has never been raised". It is saying, "where it is currently being processed, this exception cannot be raised".

Well, it is saying it. If it's conceptually unraisable, it can't be raised. I know your point is that it is only unraisable *now*, but that's not the intuitive interpretation.

And what about: Exception not propagated from > ... Or: Exception that cannot be propagated from > ... Cheers. *j

MRAB

9:58 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24/09/2013 09:06, Nick Coghlan wrote:

...

On 24 September 2013 17:34, Antoine Pitrou wrote:

...
On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan wrote:

...
You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it.

Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel.

"Unraisable" is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning.

How is it wrong? At the point where the interpreter says "This exception is now unraisable", what, precisely, is it saying that is wrong?

It isn't saying "this has never been raised". It is saying, "where it is currently being processed, this exception cannot be raised".

...
If you want something that people won't understand, you can use something like "asynchronous exception".

Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread.

...
...
Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

I've proposed other options.

"Automatically caught" says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr.

Why not just say something like "Cannot propagate exception..."; it's simpler than "Unpropagatable exception...".

Nick Coghlan

12:51 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 Sep 2013 20:06, "MRAB" wrote:

...

On 24/09/2013 09:06, Nick Coghlan wrote:

...
On 24 September 2013 17:34, Antoine Pitrou wrote:

...
On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan wrote:

...
You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it.

Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel.

"Unraisable" is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning.

How is it wrong? At the point where the interpreter says "This exception is now unraisable", what, precisely, is it saying that is wrong?

It isn't saying "this has never been raised". It is saying, "where it is currently being processed, this exception cannot be raised".

...
If you want something that people won't understand, you can use something like "asynchronous exception".

Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread.

...
...
Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains:

I've proposed other options.

"Automatically caught" says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr.

Why not just say something like "Cannot propagate exception..."; it's simpler than "Unpropagatable exception...".

That would definitely be an improvement on the status quo and avoids Antoine's concern about an adjective being interpreted as an inherent property of the exception rather than the circumstances where the exception was encountered. Cheers, Nick.

...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Glenn Linderman

4:33 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/24/2013 5:51 AM, Nick Coghlan wrote:

...

...
Why not just say something like "Cannot propagate exception..."; it's simpler than "Unpropagatable exception...".

That would definitely be an improvement on the status quo and avoids Antoine's concern about an adjective being interpreted as an inherent property of the exception rather than the circumstances where the exception was encountered.

First one I've heard that accurately and unambiguously and briefly describes the issue. +1

Cameron Simpson

25 Sep 25 Sep

11:05 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ] On 25Sep2013 08:22, Georg Brandl wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | > How about something like "Uncaught exception in __del__ | > method ignored"? It explains fairly clearly what has | > happened, and also indicates what do do about it -- | > catch it in the __del__ method. | | "Exception in __del__ caught and not propagated:" | Georg On 24Sep2013 09:33, Glenn Linderman wrote: | [MRAB]: | >> Why not just say something like "Cannot propagate exception..."; it's | >> simpler than "Unpropagatable exception...". [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1 I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated"). Why? It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made. Why not MRAB's? ("Cannot propagate exception...") While better than "Unpropagatable exception" and "unraisable" and "unreraisable", it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer. So: a small +0.1 for "Cannot propagate exception..." And: a big +2 for "Exception in __del__ caught and not propagated:". Cheers, -- Cameron Simpson Let the bullet of your thought achieve the true and final path of its trajectory before it reaches the ear of the listener, lest it plow out the other side of his head. - Henry David Thoreau

MRAB

26 Sep 26 Sep

12:17 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 26/09/2013 00:05, Cameron Simpson wrote:

...

[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ]

On 25Sep2013 08:22, Georg Brandl wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | > How about something like "Uncaught exception in __del__ | > method ignored"? It explains fairly clearly what has | > happened, and also indicates what do do about it -- | > catch it in the __del__ method. | | "Exception in __del__ caught and not propagated:" | Georg

On 24Sep2013 09:33, Glenn Linderman wrote: | [MRAB]: | >> Why not just say something like "Cannot propagate exception..."; it's | >> simpler than "Unpropagatable exception...". [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1

I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Why?

It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made.

Why not MRAB's? ("Cannot propagate exception...")

While better than "Unpropagatable exception" and "unraisable" and "unreraisable", it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer.

So: a small +0.1 for "Cannot propagate exception..."

And: a big +2 for "Exception in __del__ caught and not propagated:".

Well, my suggestion was more about eliminating the adjective+noun form; it seemed it just wasn't possible to cram the desired meaning into a single word, so it was better not to try!

Glenn Linderman

1:46 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/25/2013 5:17 PM, MRAB wrote:

...

On 26/09/2013 00:05, Cameron Simpson wrote:

...
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ]

On 25Sep2013 08:22, Georg Brandl wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | > How about something like "Uncaught exception in __del__ | > method ignored"? It explains fairly clearly what has | > happened, and also indicates what do do about it -- | > catch it in the __del__ method. | | "Exception in __del__ caught and not propagated:" | Georg

On 24Sep2013 09:33, Glenn Linderman wrote: | [MRAB]: | >> Why not just say something like "Cannot propagate exception..."; it's | >> simpler than "Unpropagatable exception...". [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1

I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Why?

It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made.

Why not MRAB's? ("Cannot propagate exception...")

While better than "Unpropagatable exception" and "unraisable" and "unreraisable", it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer.

So: a small +0.1 for "Cannot propagate exception..."

And: a big +2 for "Exception in __del__ caught and not propagated:".

Well, my suggestion was more about eliminating the adjective+noun form; it seemed it just wasn't possible to cram the desired meaning into a single word, so it was better not to try!

Georg hadn't suggested his yet when I approved MRAB's, but your reasoning is sound, Cameron, unless there is some reason that the message can't or shouldn't be as long as what Georg suggested. In between in length and clarity might be: __del__ cannot propagate exception .... All of these are less confusing that the adj+noun form, that MRAB was the first to get away from.

Nick Coghlan

4:59 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 26 September 2013 09:05, Cameron Simpson wrote:

...

On 24Sep2013 09:33, Glenn Linderman wrote: | [MRAB]: | >> Why not just say something like "Cannot propagate exception..."; it's | >> simpler than "Unpropagatable exception...". [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1

I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Why?

It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made.

Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable.

...

Why not MRAB's? ("Cannot propagate exception...")

While better than "Unpropagatable exception" and "unraisable" and "unreraisable", it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer.

It's substantially better than the status quo, though, and it shouldn't require any changes outside PyErr_WriteUnraisable. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Armin Rigo

5:42 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Hi Nick, On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:

...

...
I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable.

Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable(): - PyFile_WriteString("Exception ignored in: ", f); + PyFile_WriteString("Exception in ", f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString("\n", f); + PyFile_WriteString(" caught and not propagated:\n", f); I don't see what makes this technically different from the other solution, "Cannot propagate exception..." A bientôt, Armin.

Nick Coghlan

6:22 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 26 September 2013 15:42, Armin Rigo wrote:

...

Hi Nick,

On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:

...
...
I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable.

Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable():

- PyFile_WriteString("Exception ignored in: ", f); + PyFile_WriteString("Exception in ", f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString("\n", f); + PyFile_WriteString(" caught and not propagated:\n", f);

I don't see what makes this technically different from the other solution, "Cannot propagate exception..."

Sure, that's doable, but it dumps the full repr of "obj" in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as "obj" is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Georg Brandl

6:53 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Am 26.09.2013 08:22, schrieb Nick Coghlan:

...

On 26 September 2013 15:42, Armin Rigo wrote:

...
Hi Nick,

On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:

...
...
I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated").

Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable.

Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable():

- PyFile_WriteString("Exception ignored in: ", f); + PyFile_WriteString("Exception in ", f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString("\n", f); + PyFile_WriteString(" caught and not propagated:\n", f);

I don't see what makes this technically different from the other solution, "Cannot propagate exception..."

Sure, that's doable, but it dumps the full repr of "obj" in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as "obj" is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line.

Then this should be fine, I guess? Exception caught and not propagated in: <....> Georg

Nick Coghlan

7:17 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 26 September 2013 16:53, Georg Brandl wrote:

...

...
Sure, that's doable, but it dumps the full repr of "obj" in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as "obj" is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line.

Then this should be fine, I guess?

Exception caught and not propagated in: <....>

Sure. I still prefer something like "Could not propagate exception from:" or "Caller could not propagate exception from <repr>" that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Terry Reedy

7:51 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 9/26/2013 3:17 AM, Nick Coghlan wrote:

...

On 26 September 2013 16:53, Georg Brandl wrote:

...
...
Sure, that's doable, but it dumps the full repr of "obj" in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as "obj" is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line.

Then this should be fine, I guess?

Exception caught and not propagated in: <....>

Sure. I still prefer something like "Could not propagate exception from:" or "Caller could not propagate exception from <repr>" that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo.

With the full traceback printed, with the line where the exception originated, I do not think that the representation of the object is needed. It was a substitute for the traceback. -- Terry Jan Reedy

MRAB

23 Sep 23 Sep

11:04 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 23/09/2013 22:19, Nick Coghlan wrote:

...

On 24 Sep 2013 01:24, "Antoine Pitrou" mailto:solipsis@pitrou.net> wrote:

...
On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan mailto:ncoghlan@gmail.com> wrote:

...
On 23 September 2013 18:45, Antoine Pitrou
mailto:solipsis@pitrou.net> wrote:

...
...
...
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan mailto:ncoghlan@gmail.com> a écrit :

...
Here's what I suggest changing that error to:

...
>> del x Unraisable exception suppressed when calling > Traceback (most recent call last): File "<stdin>", line 3, in __del__ RuntimeError: Going away now

Why not simply "Exception automatically caught in <bound method C.__del__> [...]" ?

It only answers the "what" (i.e. the exception was automatically caught), without addressing the "why" (i.e. because there wasn't anything else useful the interpreter could do with it)

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*.

Ah, you mean "unreraisable". :-)

...

The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr".

Stephen J. Turnbull

24 Sep 24 Sep

12:50 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

MRAB writes:

...

...
The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*.

...

Ah, you mean "unreraisable". :-)

+1 Ugly as sin, but satisfies all other criteria (except for Antoine's "easily understandable" which simply can't be satisfied).

Nick Coghlan

7:29 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 24 September 2013 10:50, Stephen J. Turnbull wrote:

...

MRAB writes:

...
...
The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*.

...
Ah, you mean "unreraisable". :-)

+1

Ugly as sin, but satisfies all other criteria (except for Antoine's "easily understandable" which simply can't be satisfied).

If you're drawing a distinction between the first time an exception hits the eval loop and the second and subsequent times, then neither "Unraisable" nor "Unreraisable" is 100% correct. I just think it's a meaningless distinction, which is why I favour "Unraisable" - at the point in time where that message is displayed, that exception cannot be raised any further, whether it was created directly from C or was received from an underlying call back into Python code.. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Greg Ewing

23 Sep 23 Sep

10:11 p.m.

New subject: Revert #12085 fix for __del__ attribute error message

Antoine Pitrou wrote:

...

Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

How about something like "Uncaught exception in __del__ method ignored"? It explains fairly clearly what has happened, and also indicates what do do about it -- catch it in the __del__ method. -- Greg

Georg Brandl

25 Sep 25 Sep

6:22 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

Am 24.09.2013 00:11, schrieb Greg Ewing:

...

Antoine Pitrou wrote:

...
Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__).

How about something like "Uncaught exception in __del__ method ignored"? It explains fairly clearly what has happened, and also indicates what do do about it -- catch it in the __del__ method.

"Exception in __del__ caught and not propagated:" Georg

Antoine Pitrou

22 Sep 22 Sep

8:19 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy wrote:

...

...
In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021),

Lets call that a buglet ;-). Not really harmful, but annoying.

It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system.

...

Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it?

Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor. Making them warnings means they could be silenced depending on the current warning settings. Regards Antoine.

Georg Brandl

8:48 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On 09/22/2013 10:19 AM, Antoine Pitrou wrote:

...

On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy wrote:

...
...
In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021),

Lets call that a buglet ;-). Not really harmful, but annoying.

It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system.

...
Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it?

Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor.

Making them warnings means they could be silenced depending on the current warning settings.

Which is not too bad, right? (Assuming it's not silent by default.) However, I'm not sure invoking the whole complicated warning filtering and emitting code is what we want to do in a destructor... Georg

Antoine Pitrou

8:55 a.m.

New subject: Revert #12085 fix for __del__ attribute error message

On Sun, 22 Sep 2013 10:48:33 +0200 Georg Brandl wrote:

...

On 09/22/2013 10:19 AM, Antoine Pitrou wrote:

...
On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy wrote:

...
...
In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021),

Lets call that a buglet ;-). Not really harmful, but annoying.

It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system.

...
Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it?

Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor.

Making them warnings means they could be silenced depending on the current warning settings.

Which is not too bad, right? (Assuming it's not silent by default.)

The default is to print a given warning message only once, which isn't the normal semantics of exceptions.

...

However, I'm not sure invoking the whole complicated warning filtering and emitting code is what we want to do in a destructor...

Good point, too :-) Regards Antoine.

3864

Age (days ago)

3869

Last active (days ago)

List overview

Download

48 comments

14 participants

participants (14)

Antoine Pitrou
Armin Rigo
Cameron Simpson
Ethan Furman
Georg Brandl
Glenn Linderman
Greg Ewing
Guido van Rossum
Jan Kaliszewski
MRAB
Nick Coghlan
R. David Murray
Stephen J. Turnbull
Terry Reedy

Revert #12085 fix for __del__ attribute error message

Jan Kaliszewski

Cameron Simpson

tags

participants (14)

Revert #12085 fix for del attribute error message