Alexander Belopolsky <[email protected]> wrote: > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl <[email protected]> wrote: > .. > > In any case, this is coming pretty late; beta 2 is scheduled for this > > weekend, and even if this is something that only kicks in when all hope > > is lost anyway, it is a new feature. I should like to hear approval > > from a few more devs before I will let this go into 3.2. > > > > I am -1 on the feature as written. I would be -0 if it did not > install signal handlers by default and even better was implemented in > a separate module, not in core.
I would not want this to be the default either. I think the output is not particularly informative: $ ./python Lib/test/crashers/gc_inspection.py (<object object at 0x7f01827ad870>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>) Fatal Python error: Segmentation fault Traceback (most recent call first): File "Lib/test/crashers/gc_inspection.py", line 29 in g File "Lib/test/crashers/gc_inspection.py", line 32 in <module> Segmentation fault Segmentation fault Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] It's hard to get signal handlers right across multiple platforms; even SIGINT catching does not work properly on OpenBSD: http://bugs.python.org/issue8714 In short, I agree that having more signal handlers by default is not a good idea. Stefan Krah _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
