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 <tjreedy@udel.edu> wrote:
On 9/21/2013 6:15 PM, R. David Murray wrote:
On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy <tjreedy@udel.edu> 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 <bound method C.__del__ of
<__main__.C object at 0x000000000351A198>> 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: <bound method C.__del__ of <__main__.C object at 0x00000000039946D8>>
Traceback (most recent call last):
  File "<pyshell#0>", 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)