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 <tjre...@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 <tjre...@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<https://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: https://mail.python.org/**mailman/options/python-dev/** > guido%40python.org<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
