On 09/22/2013 10:19 AM, Antoine Pitrou wrote: > On Sat, 21 Sep 2013 19:55:05 -0400 > Terry Reedy <tjre...@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.) However, I'm not sure invoking the whole complicated warning filtering and emitting code is what we want to do in a destructor... Georg _______________________________________________ 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
