> > Hm... hmmmm... fixing this has been suggested before, but always
> > foundered on the fact that creating a closure required a cycle, which
> > would leak memory. Now we have an optional GC that should handle
> > this, so maybe fixing it can be revisited. (But this would mean that
> > GC is essentially no longer optional -- maybe too radical a thing to
> > do before we're sure about the new GC. 2.1, maybe?)
>
> I think I'd rather have this solved by weak references then by building
> cycles. Cycles are evil even in the face of GC -- you have undetermined
> finalization.
But in this case, there aren't any custom finalizers involved in the
cycle (although there may be some *hanging off* the cycle).
E.g. after:
def f():
def g(): pass
f()
we have (taking some notational liberties and simplifications):
globals = {'f': f}
f.func_globals = globals
locals = {'g': g}
g.func_globals = locals # or maybe g.func_parent = locals
In other words the cycles are between a dictionary and a function
object:
globals <--> f
locals <--> g
I don't see any finalization issues.
--Guido van Rossum (home page: http://www.pythonlabs.com/~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