This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Expose a dictionary of interned strings in sys module
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: rhettinger, ronaldoussoren, rushter, serhiy.storchaka
Priority: normal Keywords:

Created on 2018-08-12 09:36 by rushter, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (7)
msg323437 - (view) Author: (rushter) Date: 2018-08-12 09:36
Python provides an ability to intern strings (sys.intern). It would be useful to expose a read-only dictionary of interned strings to the Python users so we can see what kind of strings are interned. 

It takes minimal changes since internally it's just a dictionary. Is this worth adding to the sys module?
msg323440 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2018-08-12 10:44
Could you explain why this would be useful?
msg323450 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-08-12 17:01
I wouldn't want a user to be able to mutate the dictionary directly (otherwise, non-strings could be added).
msg323453 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2018-08-12 20:09
Another reason for not wanting write access to the sys.intern dictionary is that this dictionary does not own references to its keys and values.
msg323455 - (view) Author: (rushter) Date: 2018-08-12 20:57
Thank you, I agree. I can't come up with practical use cases other than my curiosity. 

Is it possible to somehow expose the dictionary in the debug build of Python? Currently, there is no way to access it from the interpreter even with ctypes.
msg323468 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2018-08-13 08:23
IMHO we shouldn't expose the intern dictionary without there being a clear, and good enough, use case for doing so.  

Exposing the dictionary decreases implementation flexibility, and increases requirements on other implementations.  One example of the former: at least in theory the interning dictionary could be a set, but we couldn't make that change if the dictionary were exposed in the API.

With current information I'm -1 on exposing the dictionary, and -0 on doing that for debug builds only.
msg323470 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-08-13 09:38
I concur with Ronald. Using a dict instance is an implementation detail. CPython could use a dict, a set, a hashtable implementation from Modules/hashtable.c, or the HAMT implementation from Python/hamt.c. Other Python implementations can have other options.
History
Date User Action Args
2022-04-11 14:59:04adminsetgithub: 78567
2018-08-13 09:38:52serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg323470

resolution: rejected
stage: resolved
2018-08-13 08:23:44ronaldoussorensetmessages: + msg323468
2018-08-12 20:57:51rushtersetmessages: + msg323455
2018-08-12 20:09:33ronaldoussorensetmessages: + msg323453
2018-08-12 17:01:08rhettingersetnosy: + rhettinger
messages: + msg323450
2018-08-12 10:44:04ronaldoussorensetnosy: + ronaldoussoren
messages: + msg323440
2018-08-12 09:36:13rushtercreate