> > But in this case, there aren't any custom finalizers involved in the
> > cycle (although there may be some *hanging off* the cycle).
>
> Yes, but those finalizers hanging off the cycle would occur in some random
> time in the future, not right now, hence rendering the
>
> def f():
> fp = open("fff")
> pass
>
> idiom dangerous, since you're not sure how long fp will remain open.
Aha. You're complaining about the finalizers being postponed
arbitrarily. I thought you were complaining about the issue of
finalization order *within* the cycle.
Since this is still an improvement over current practice (where a
finalizer hanging off a cycle may never be called) and there are no
serialization issues, I don't see the problem.
If you want to use weak references, please try to specify *in detail*
which objects would have weak references to which other objects and
how the system would resolve these... I'm never sure that things can
be made 100% safe using this technique, so it may help to spell it out
for me!
--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