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

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

[Tim]

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 worldwide.

I think it would be possible to have two versions of PyGCREFSUNTRACKED, one being, say, -5. PyGCREFSUNTRACKEDANDKEEPITTHATWAY would be what you get when you call PyObjectGCUnTrack; 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 visit_reachable().

More information about the Python-Dev mailing list