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

Nick Coghlan ncoghlan at gmail.com
Tue Sep 24 10:06:15 CEST 2013


On 24 September 2013 17:34, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 24 Sep 2013 17:25:10 +1000
> Nick Coghlan <ncoghlan at gmail.com> 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 at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list