[Python-Dev] Revert #12085 fix for __del__ attribute error message
Antoine Pitrou
solipsis at pitrou.net
Sun Sep 22 10:55:37 CEST 2013
On Sun, 22 Sep 2013 10:48:33 +0200
Georg Brandl <g.brandl at gmx.net> wrote:
> On 09/22/2013 10:19 AM, Antoine Pitrou wrote:
> > On Sat, 21 Sep 2013 19:55:05 -0400
> > Terry Reedy <tjreedy at udel.edu> 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.
More information about the Python-Dev
mailing list