Skip to content

Conversation

@davidhewitt
Copy link
Member

Expands the test suite on Python 3.14t:

  • uses a mutex to protect tests which modify sys.unraisablehook, as it's a global variable, and enable them all
  • drop the mutex from tests which use warnings.capture_wanings, as it's thread-safe on 3.14t

@davidhewitt davidhewitt requested a review from ngoldbaum October 16, 2025 13:55
Copy link
Contributor

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had one minor question and comment but otherwise this looks great. A few other comments too.

let instance = Py::new(py, ReleaseBufferError {}).unwrap();
let env = [("ob", instance.clone_ref(py))].into_py_dict(py).unwrap();

assert!(capture.borrow(py).capture.is_none());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not obvious to me why this got deleted, any particular reason? There's a similar pattern in test_exceptions.rs below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm it was just awkward to assert that the unraisable hook hadn't been called yet.

I've found a better pattern where the closure gets access to the hook so it can retrieve the value, will push that and restore this.

assert_eq!(err.to_string(), "ValueError: oh dear");
assert!(object.is(&instance));

capture.borrow_mut(py).uninstall(py);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even without the locking the new API is nicer without this explicit uninstall step.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, much less error prone.

@davidhewitt davidhewitt enabled auto-merge October 16, 2025 19:13
Comment on lines +657 to +662
// On the free-threaded build, dropping an object on its non-origin thread
// will not immediately drop it because the refcounts need to be merged.
//
// Force GC to ensure the drop happens now on the wrong thread.
py.run(c_str!("import gc; gc.collect()"), None, None)
.unwrap();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In hindsight this should have been obvious why this test was failing; for a while I was worried it was a refcounting bug on PyO3's end.

@davidhewitt davidhewitt added this pull request to the merge queue Oct 17, 2025
Merged via the queue into PyO3:main with commit 999ee8a Oct 17, 2025
41 of 42 checks passed
@davidhewitt davidhewitt deleted the 3.14t-tests branch October 17, 2025 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants