We're all consenting adults here. Tampering with the private data of an extension module is a well-known way to crash Python.
Is it? I am not aware of any such example in the standard library. I am sure that it would be considered as a bug. The only (internal and expected) ways to crash the Python interpreter from Python are currently to abuse new.code() or gc.getreferents(). If an extension module allows this kind of tampering from Python code I'd consider it poorly written.
As I had always understood it, we go to great lengths to ensure that Python itself and the standard library are as robust as possible and nearly impossible to crash. However, extension authors, by definition, are writing *extensions* and are not under the supervision of the Python development team. It is, of course, trivial to write an extension which will (intentionally) crash Python, and just as easy to (unintentionally) write one with a flaw which allows crashes. Thus, I have always understood that as soon as you use an extension, Python no longer offers any guaranties.
Of course, the author of the EXTENSION may offer such a guarantee. Depending on who it is, and how widely-used and well-tested the extension is, you may choose to trust such a guarantee. But I've always thought that was separate from Python's promise of "no crashes".
As for handling this particular issue, I agree with your suggestion:
I'd advocate using fresh instances of 'object' as keys instead of strings, which is even safer.
Good advice for extension authors AND for pure-python writers whenever they don't want their values tramped on. Of course, one can still call keys() on the dictionary to obtain the key if one is *trying* to break (or monkeypatch) the extension, but that's where I think the "consenting adults" rule applies.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.