Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote: > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl <g.brandl at gmx.net> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4