[Timothy Delaney] > The #1 most important consideration here is backwards > compatibility IMO. Whilst I would be personally unaffected by > this change (allowing interned strings to be collected), we've > already had examples of people and code that would be. Have we? I posted an example I made up -- I've written and seen code *close* to that, but not close enough to actually break if interned strings were to get collected. I also saw Jack's interned-string refcount abuse in an isolated part of the core Mac support code, but breaking core code never counts because we have 100% control over the core (if interned strings were to get collected, we'd fiddle the Mac code for the same release, and nobody would be the wiser). I don't recall hearing about anything else here, and I don't know of anything else. Any subsystem that can waste an unbounded amount of memory is a potential cause of user headaches. I don't like immortal interned strings, and I don't like the unbounded int or float free lists either. It's also not good that pymalloc never returns arenas to the system, although at least that was carefully designed so that arenas not in use can become and stay paged out (e.g., it doesn't periodically "tickle" them as part of general bookkeeping -- when they're unused by the user, they're also untouched by pymalloc). So far, I don't know of any real loss that would occur as a result of reclaiming unreferenced interned strings.
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