From: Guido van Rossum <guido@python.org>
> > In Jython as long as we want to support Java 1.1
> > (and AFAIK Finn still will) we cannot make interned
> > string always mortal.
> > So it is OK if CPython goes this route, but the Python
> > manual should say that it is unspecified whether
> > intern results are mortal or immortal or nothing on the subject
> > (now it explicitly says immortal).
>
> That's okay. Immortality of interned strings is mostly an issue for
> very long running server processes that take connections from
> arbitrary clients; the issue is that arbitrary client data
> accidentally gets immortalized because it is tried as an attribute
> name or mapping key. While Jython *could* be used in JSP server
> setups, I expect that most long-running Python servers are using
> CPython and a framework like Zope, Twisted or Quixote.
Ok, thinking a bit more it's a kind of trade-off
('is' speed for Python strings and 2 ref plus an int vs. a ref a boolean and an
int
of space required for Python strings (which is kind of VM depedent and should
be measured)), we could make
the Python interned strings mortal but anyway:
- we use Java interned strings (immortal anyway) for class,module, and instance
dictionaries anyway.
- for the rest Python interned strings are just the result of intern()
with the property that the wrapped Java string is also a Java interned one
(so immortal).
so the point for us is a bit muddy.
regards.
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