On Sun, 22 Sep 2013 10:48:33 +0200 Georg Brandl <g.bra...@gmx.net> wrote:
> 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.) 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. _______________________________________________ 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