STINNER Victor added the comment:
Never rely on the GC. Avoid cycles by using the weakref module.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21351
___
Min RK added the comment:
Thanks for clarifying that there is indeed a reference cycle by way of the
module, I hadn't realized that.
The gc blocking behavior is exactly why I brought up the issue. The real code
where this causes a problem (rather than the toy example I attached) is in
pyzmq,
Tim Peters added the comment:
There's no way to influence finalization order for objects in cycles, and there
never was. So nothing actually changed in that respect ;-) What did change is
that Python used to forcibly break many module-level cycles in a way that just
happened to result in
Min RK added the comment:
Thanks for your help and patience. Closing as slightly unfortunate, but not
unintended behavior.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21351
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21351
___
___
Python-bugs-list
Tim Peters added the comment:
After more thought, I don't think the user can do anything to influence
finalization order in cases like this, short of adding del statements (or
moral equivalents) to break cycles before the interpreter shuts down.
Fine by me ;-) Something CPython could do,
New submission from Min RK:
Reference counts appear to be ignored at process cleanup, which allows
inter-dependent `__del__` methods to hang on exit. The problem does not seem to
occur for garbage collection of any other context (functions, etc.).
I have a case where one object must be
Nathan Stocks added the comment:
This affects me as well. I have to manually clean up objects in the correct
order in script I am working on under 3.4.0. I have this problem under both OS
X 10.9.2 Mavericks and under CentOS 6.5
--
nosy: +nathan.stocks
Tim Peters added the comment:
Just noting that, for me, the problem goes away if
del c, c2
is added as the last line of the test. This suggests the problem is due to
changes in end-of-life module cleanup.
Without that line, I see 3 kinds of output:
1.
del child
del child
del parent
parent
Changes by Tim Peters t...@python.org:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21351
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
(the 3 kinds of output are probably due to hash randomization)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21351
___
Antoine Pitrou added the comment:
Looking into it, it's normal for refcounts to be ignored: those objects
belong to reference cycles:
tstgc.__dict__
- p (or c, or c2)
- p.__class__ (i.e. Parent, or Child respectivel))
- Parent.__dict__
- Parent.__del__ (or Parent.__init__, or Parent.child)
-
Tim Peters added the comment:
I think Antoine is right on all counts. The most surprising bit may be that p,
c, and c2 are in reference cycles, but - surprising or not - that's always been
true. The reason it worked before 3.4 is that CPython happened to break the
cycles via the nasty hack
13 matches
Mail list logo
