Note that it's easy to make objects cooperate with gc. We've historically
only done so when the need was clear, because the gc header takes about a
dozen extra bytes per gc-tracked object. There aren't enough files or
xreadlines objects in existence to care about the extra memory burden here,
though; we simply thought that objects of these types could never be in
cycles. OTOH, if that means lazy code like
for fname in os.listdir('.'):
for line in file(fname):
n += 1
would accumulate an ever-growing number of open file objects until gc
happened to run and break cycles, I expect a lot of CPython programs would
"suddenly break" (they rely on refcount semantics now closing the anonymous
file object the instant it becomes unreachable).
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