Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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 " 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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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 " 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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Georg Brandl]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Armin Rigo]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Glenn Linderman]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[MRAB]

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!


___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Cameron Simpson]

[ 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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Georg Brandl]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Glenn Linderman]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Jan Kaliszewski]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[MRAB]

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...".
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Stephen J. Turnbull]

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).
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[MRAB]

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


On 24 Sep 2013 01:24, "Antoine Pitrou" mailto:solip...@pitrou.net>> wrote:
 >
 > On Mon, 23 Sep 2013 18:51:04 +1000
 > Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
 > > On 23 September 2013 18:45, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
 > > > Le Mon, 23 Sep 2013 18:17:51 +1000,
 > > > Nick Coghlan mailto:ncogh...@gmail.com>> a
écrit :
 > > >>
 > > >> Here's what I suggest changing that error to:
 > > >>
 > > >> >>> del x
 > > >> Unraisable exception suppressed when calling  > >> of <__main__.C object at 0x7f98b8b61538>>
 > > >> Traceback (most recent call last):
 > > >>   File "", line 3, in __del__
 > > >> RuntimeError: Going away now
 > > >
 > > > Why not simply "Exception automatically caught in  > > 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".



___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Ethan Furman]

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 "", line 3, in __del__
RuntimeError: Going away now


Why not simply "Exception automatically caught in  [...]" ?


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~
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[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.

--
Greg
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Ethan Furman]

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~
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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  > > >> of <__main__.C object at 0x7f98b8b61538>>
> > > >> Traceback (most recent call last):
> > > >>   File "", line 3, in __del__
> > > >> RuntimeError: Going away now
> > > >
> > > > Why not simply "Exception automatically caught in  > > > 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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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  > >> of <__main__.C object at 0x7f98b8b61538>>
> > >> Traceback (most recent call last):
> > >>   File "", line 3, in __del__
> > >> RuntimeError: Going away now
> > >
> > > Why not simply "Exception automatically caught in  > > 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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[R. David Murray]

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  > >> of <__main__.C object at 0x7f98b8b61538>>
> > >> Traceback (most recent call last):
> > >>   File "", line 3, in __del__
> > >> RuntimeError: Going away now
> > >
> > > Why not simply "Exception automatically caught in  > > 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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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 "", line 3, in __del__
RuntimeError: Going away now


Why not simply "Exception automatically caught in  [...]" ?


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


___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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  >> of <__main__.C object at 0x7f98b8b61538>>
> >> Traceback (most recent call last):
> >>   File "", line 3, in __del__
> >> RuntimeError: Going away now
> >
> > Why not simply "Exception automatically caught in  > 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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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 > of <__main__.C object at 0x7f98b8b61538>>
>> Traceback (most recent call last):
>>   File "", line 3, in __del__
>> RuntimeError: Going away now
>
> Why not simply "Exception automatically caught in  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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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  of <__main__.C object at 0x7f98b8b61538>>
> Traceback (most recent call last):
>   File "", line 3, in __del__
> RuntimeError: Going away now

Why not simply "Exception automatically caught in  [...]" ?

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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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 "", 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 "", 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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Greg Ewing]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Glenn Linderman]

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..."
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Ethan Furman]

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


On 23 Sep 2013 06:38, "Terry Reedy" mailto:tjre...@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:tjre...@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~
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Guido van Rossum]

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)
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Nick Coghlan]

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 > > 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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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

On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy mailto:tjre...@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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Guido van Rossum]

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)
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Georg Brandl]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Antoine Pitrou]

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.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Guido van Rossum]

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 >> <__main__.C object at 0x0351A198>> 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:  0x039946D8>>
> 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
> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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: 0x039946D8>>

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
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

[R. David Murray]

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  <__main__.C object at 0x0351A198>> ignored

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?
>From the issue, it sounds like it could be considered either (or most
likely, both).

--David
___
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/archive%40mail-archive.com

[Python-Dev] Revert #12085 fix for __del__ attribute error message

[Terry Reedy]

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 <__main__.C object at 0x0351A198>> 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

___
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/archive%40mail-archive.com