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

Nick Coghlan ncoghlan at gmail.com
Mon Sep 23 10:17:51 CEST 2013


On 23 September 2013 16:11, Greg Ewing <greg.ewing at canterbury.ac.nz> 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: <bound method C.__del__ of <__main__.C object at
0x7f98b8b61538>>
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 <bound method C.__del__
of <__main__.C object at 0x7f98b8b61538>>
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 at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list