Den sön 27 juli 2025 kl 04:55 skrev Yasuhito FUTATSUKI < futat...@yf.bsdclub.org>:
> Hello, > > On 2025/07/27 8:22, Daniel Sahlberg wrote: > > > I'm not very fond of the idea of just disabling the tests under 3.14, > > chances are we'll never come to re-writing to weakrefs and then we've > > basically lost a test. > > We've already lost a test on under Python >= 3.14, if we cannot explain > that the test is correct. I think such a test tests nothing. > > @Yasuhito FUTATSUKI <futat...@yf.bsdclub.org> Do I understand it correctly > > that you are concerned why we can keep the existing expected count ... > > > > 434: for baton in editor.batons: > > 435: self.assertEqual(sys.getrefcount(baton[2]), 2, > > ^ HERE > > 436: "leak on baton %s after replay without errors" > > 437: % repr(baton)) > > 438: del e_baton > > > > ... but we have to modify it ... > > > > 439: self.assertEqual(sys.getrefcount(e_ptr), expected, > > ^ HERE > > 440: "leak on editor baton after replay without > > errors") > Briefly, no. I worry about our test using sys.getrefcount() does not > work as we expected under modified reference counting. > Isn't the issue at hand here that the interpreter - sometimes - borrow argument already on the stack (and thus not changes refcount)? That "sometimes" is not very well documented, the best I can find is in the PR[1]: "when we can be sure that the reference in the frame outlives the reference that is pushed onto the operand stack" This seems to affect the call to sys.getrefcount(). The cases when refcount is modified involve swig-generated classes (libsvn.core.svn_merge_range_t and libsvn.delta.svn_delta_editor_t), but I don't know if that helps explaining. It seems like others[2] have had to make similar changes as in r1926575. > > > Can you outline your idea for using weakrefs? > > Just collecting weakrefs of the target objects and check them before > and after removing those objects. > "collecting" as in the BatonCollector class? But the difference in refcount is on the e_ptr object which are not collected as far as I can see. Do I miss something? I would argue that the tests are still reasonably valid even if we have to modify refcount as long as we only change between Python 3.13 and 3.14 (and everything else is the same). If we at one point change the code and miss an INCREF/DECREF that should show up in the test cases as long as we stick to the same "known good" Python version. > Cheers, > -- > Yasuhito FUTATSUKI <futat...@yf.bsdclub.org> > > Cheers, Daniel [1] https://github.com/python/cpython/pull/130708 [2] https://github.com/python-greenlet/greenlet/pull/442/files
