Skip to content

Conversation

@vstinner
Copy link
Member

@vstinner vstinner commented Dec 11, 2025

@vstinner
Copy link
Member Author

cc @colesbury

Copy link
Contributor

@colesbury colesbury left a comment

Choose a reason for hiding this comment

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

I don't think we should do this:

  • The public API is that these are zero initialized. That's important - it simplifies a lot of things, because it's really easy to zero-alloc things.
  • (PyMutex){0} is the standard zero initialization idiom in C11. It doesn't leak internals and doesn't matter how many fields PyMutex has.
  • PyMutex_STATIC_INIT is misnamed as it's not used for static initialization.

@bedevere-app
Copy link

bedevere-app bot commented Dec 11, 2025

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@vstinner
Copy link
Member Author

PyMutex_STATIC_INIT is misnamed as it's not used for static initialization.

Yeah, I hesitated with PyMutex_INIT name.

@emmatyping
Copy link
Member

I agree with everything Sam mentioned why we shouldn't do this.

I'd also say we should avoid introducing new macros in general in the C API. Regardless of whether Rust becomes part of CPython itself, Rust and other 3rd-party FFI bindings need to handle macros specially, and we should avoid giving those projects more work.

@vstinner
Copy link
Member Author

Ok, I abandon my PR. Let's not do that :-)

@vstinner vstinner closed this Dec 12, 2025
@vstinner vstinner deleted the pymutex_static_init branch December 12, 2025 13:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants