[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 > _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 visit_reachable(). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
