> 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. I can only repeat what I said before about this: """But the vast majority of C code does *not* depend on this. I'd rather keep PyString_InternInPlace(), so we don't have to change all call locations, only the very rare ones that rely on this.""" > 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". It wasn't that. --Guido van Rossum (home page: http://www.python.org/~guido/)
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