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-August/028064.html below:

[Python-Dev] Re: Last call: mortal interned strings

[Python-Dev] Re: Last call: mortal interned strings [Python-Dev] Re: Last call: mortal interned stringsOren Tirosh oren@hishome.net
Tue, 20 Aug 2002 07:55:50 +0300
I see that this has been checked in. 

My version:

	PyString_InternInPlace - immortal
	PyString_Intern - mortal 

Your version:

	PyString_InternInPlace - mortal
	PyString_InternImmortal - immortal

My version favors backward compatibility - existing modules will not break 
if they rely on the immortality of interned strings.

Your version appears to maximize the benefit of interned strings - existing
modules automatically get the new mortal semantics without requiring any 
changes.

I was wondering what was the rationale behind this decision.

If the only reason was that the name PyString_Intern is not descriptive
enough it can be renamed to something like PyString_InternReference to
make it clear that it operates on a reference to a string and modifies 
it "in place".

	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