On Mon, Jul 01, 2002 at 09:03:22AM +0200, Martin v. Loewis wrote: > Oren Tirosh <oren-py-d@hishome.net> writes: > > > In stringobject.c most references to ob_sinterned are to initialize it. The > > only place that uses it is string_hash: if ob_sinterned is not NULL it uses > > the hash of the string it points to instead of the current string object. > > This is not true: PyString_InternInPlace has I meant references to ob_sinterned outside the actual implementation of PyString_InternInPlace. > > Summary: As far as I can tell, indirectly interned strings are redundant. > > Without them the ob_sinterned field is effectively a boolean flag. > > > > Can anyone explain why interning is implemented the way it is? Can anyone > > explain why Mac/Python/macimport.c is messing with ob_sinterned? > > I'm not sure what meaning you would assiocate with the boolean > flag. "This string is interned. It is equal to another interned strings iff they are the same object" ... > If that code prints "reinterning", it can efficiently intern the > argument, but couldn't with your change. > > I agree that this is very rare, but in the test suite, it triggers 5 > times in test_descr. test_descr is not exactly typical Python code... What bothers me is that of the two places that check if a string is interned one is a no-op and the other never happens. 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