A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-July/026100.html below:

[Python-Dev] Alternative implementation of string interning

[Python-Dev] Alternative implementation of string interningOren Tirosh oren-py-d@hishome.net
Tue, 2 Jul 2002 06:37:48 -0400
On Tue, Jul 02, 2002 at 11:17:15AM +0200, Jack Jansen wrote:
> 
> On Monday, July 1, 2002, at 11:12 , Tim Peters wrote:
> 
> >[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.
> 
> The macimport code relies on the ids remaining the same. But it is easy 
> to fix (just add an incref). I'll also change it to use 
> PyString_CheckInterned.

No, an incref there would leak references.  Nothing needs to be changed.

Any code with correct reference counting will not notice any difference
with this patch.  The only problem that could occur is if Python code uses 
the id function, stores the integer result but doesn't keep an actual 
reference to the string object and no other code does, either. Even this is 
not a problem yet unless the code also expects that if the same string is 
ever interned again it will get the same integer id and breaks if it
doesn't.  I can't believe anyone is stupid enough to do that.  Using the id 
function this way is equivalent to an uncounted reference. 

BTW, my patch already takes care of PyString_CheckInterned in macimport.c

	Oren




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