[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