Michael Foord writes: > It seemed from the discussion that the biggest barrier to enabling it by > default was possible difficulties when embedding Python (multiple > interpreters, potential conflicts with application signal handling). A > public C-API to disable the functionality per interpreter would be one > option for this.
That's not really good enough. The point of installing a handler like this is to "catch them squirmers". All you have to do is override some incautious developer's own squirmer-trap handler once, and Python has made an Enemy-For-Life. (This happened to XEmacs with esound. I immediately removed esound and anything that depends on it from my workstation. ;-) YMMV and you may think that that is not so important; my point is that the proposal to provide a way to disable does not at all address the objection. > Another possibility would be providing a C-API to enable it and > have the Python interpreter application call this, so that the > functionality remains off by default for embedded interpreters but > on for normal uses. I think this is heading in the right direction. Note: My own experience with such handlers has been positive, but it does not involve embedding interpreters in either direction, so not really helpful in addressing this objection. Precisely *because* my own experience has been positive, I worry about interfering with some third party's handler. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com