On Sun, Aug 18, 2002 at 11:15:08PM -0400, Tim Peters wrote: > [Oren Tirosh] > > ... > > The problem is in C extension modules. In C there is an incentive to rely > > on the immortality of interned strings because it makes the code simpler. > > Are you sure about that? I haven't seen it. > > > There was an example of this in the Mac import code. > > Code *inside* the core can play any dirty tricks it likes, because we > guarantee to keep it working as things change across releases. But, AFAICT, > we have no evidence that anything outside the core abuses this stuff. I doubt that whoever wrote that code was thinking "hey, this is part of the core so I can do this". More likely he was just following the *documented* promise that interned string are immortal. There may be extension modules outside the core that also rely on this promise. > > PyString_InternInPlace should probably create immortal interned strings > > for backward compatibility (and deprecated, of course) > > I still doubt it matters to anything outside the core. Perhaps I'm being overly cautious about breaking promises. If both you and Guido say it's OK who am I to argue... > > Maybe PyString_Intern should be renamed to PyString_InternReference to > > make it more obvious that it modifies the pointer "in place". > > You're talking about a function that doesn't exist now, right (I don't > recognize the name PyString_Intern, and neither it nor > PyString_InternReference scream anything obvious to me)? PyString_Intern is the name of the function in my patch that creates a mortal interned string. PyString_InternInPlace creates immortal interned strings for compatibility. 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