[Oren Tirosh, on <http://python.org/sf/576101>]
> ...
> Interned strings are no longer immortal. They die when their refcnt
> reaches 0 just like any other object.
This may be a problem. Code now can rely on that id(some_interned_string)
stays the same across the life of a run.
> ...
> Can anyone explain why they were implemented with a pointer in the first
> place? Barry?
It will have to be Guido. He made a plausible case to me once about why the
indirection is there, but it may be an optimization that's no longer
important. At the time interned strings were introduced, extension modules
had mountains of code of the form:
/* at module init time, in one or more modules */
static PyObject *spam_str = PyString_FromString("spam");
/* in various module routines */
PyObject_SetAttr(someobject, spam_str, user_supplied_value);
and PyObject_SetAttr() was changed to make spam_str what you called an
"indirectly interned" string by magic. This was (or at least Guido thought
it was <wink>) an important optimization at the time.
Extension modules written after interned strings were introduced can exploit
interning directly, a la
/* at module init time, in one or more modules */
static PyObject *spam_str = PyString_InternFromString("spam");
and the core was reworked to do that too (note that this optimization wasn't
directed at the core -- it could well be that core code never creates an
indirectly interned string). I don't know how many extension modules still
implicitly rely on indirect interning for a speed boost. Zope doesn't, and
that's all that really matters <wink>.
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