It seems to me that any time there are more than two CObjects around we have a good chance of causing mischief: >>> import cStringIO, _curses >>> cStringIO.cStringIO_CAPI = _curses._C_API >>> import cPickle >>> cPickle.dumps(range(10)) Illegal instruction (if you're trying this at home, starting python with -E might be necessary to make sure cPickle hasn't been imported already). Question 1: do we care? I think we do: "no core dumps" is a pretty strong Pythonic principle, even though this is certainly a "doctor it hurts when I do this" situation. OTOH, Armin's gc.get_referrers hack was deemed allowable. It seems to me that it would be more sensible to have a dict mapping names (maybe just module names...) to cobjects in the interpreter state. I guess there might be a way of getting ahold of the dict with the gc module (though I can't think of one off hand). This wouldn't be a difficult change, and if the CObjects are left in the module dicts, it shouldn't even do that much damage to binary compatibility. Thoughts? Cheers, mwh (who also notices that the cobject section in Doc/ext/ could do with being updated to use PyCObject_Import...)
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