> Hmm! I bet we could go a long away leaving gc out of this entirely: > BUILD_TUPLE in ceval.c could check the types of the objects it > stuffs into a new tuple, and untrack it immediately then if it were > safe to do so. But this still takes time, and most tuples never make it into GC, so it's wasted time, isn't it? I'd put such code in tuplevisit (assuming it's safe to call GC_UnTrack there). > And tupleconcat() could mindlessly inherit trackedness from the > logical "or" of its inputs' trackedness. Would that get 80% of the > potential benefit with 5% of the potential work? Too sophisticated already. ;-) --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