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.
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