We don't need critical sections in __new__. The __init__ functions is a bit more debatable; in theory one can call __init__ on an already initialized object. For now I'd like to avoid locking/critical_sections in __init__, but we may want to revisit that later.

Updated, and made a small performance test on my local machine, and not seen any noticeable performance difference before and after the commits. I just realized that in the default build (no --disable-gil flag), the critical sections macros are just dummy macro, so there should not be performance issue.

I found that it's really common for the getters and setters to add the critical section guard, and makes the work repeatability and error-prone.

Can we add some code generation process, like the argument clinic stuff, or just introduce a C macro to reduce the repeatability, like:

static PyObject *
xxx_getter_impl(PyObject *self, void * context) {
    // original codes.
}

Py_CRITICAL_SECTION_GETTER(xxx_getter);  // Using this macro to generate the `xxx_getter` function and call the old `xxx_getter_impl`

@colesbury

@aisk, Yeah I think adding support for getters/setters to Argument Clinic is the way to do it.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.