[Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

Tim Peters tim.peters at gmail.com
Sat Sep 25 01:20:22 CEST 2010

>> I assume this is unintended because (a) the docs weren't changed to
>> warn about this; and, (b) it's wrong ;-)

[Martin v. Löwis]
> It seems Jim is happy with (or has at least accepted) the behavior
> change. Would you still like to see it fixed (or, rather, have the
> 2.6 state restored)?

"it's wrong ;-)" meant what it said - the track/untrack APIs weren't
intended to be hints Python is free to ignore, they were meant to give
the user control over whether and when their objects participated in
cyclic gc.  It's true that their (by far) most common uses are
mandatory, to avoid tracking before a new object is sane, and to
untrack again before it becomes insane when it's being torn down, but
those were not the only intended uses.

That said, the optimization 2.7 introduced probably has value that
shouldn't be dismissed either.

BTW, if it had taken Jim 1000 lines of new code instead of 2 to worm
around the regression in ZODB under Python 2.7, I expect he'd be
singing a different tune ;-)  I view his experience as akin to the
canary in the coal mine, albeit likely a mine with very few miners

> I think it would be possible to have two versions of
> _PyGC_REFS_UNTRACKED, one being, say, -5.
> _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY would be what you get
> when you call PyObject_GC_UnTrack; the code to do automatic
> tracking/untracking based on contents would use some other
> new API (which would be non-public in 2.7.x).

Looks like a promising idea!  gcmodule.c's IS_TRACKED macro would have
to change to check both states, and likewise the debug assert in

More information about the Python-Dev mailing list