I think that NEWS won't hurt in this case.

I won't block any of this but view it all as unnecessary code churn (no user's life is now better). Also, when I was actively developing the C API for sets, it was convenient to have the caller and callee in the same file.

Also, git blame can no longer track these lines to their original commits or identify the person who made them.

Even though its value is subjective, this work does make the code nicer, and I think it's probably more beneficial to have a contributor do this kind of work, gaining experience in the codebase, than any of the minor drawbacks you mention.

@sobolevn: I hesitate to backport this one. Maybe keeping these tests in 3.12 is safer. What do you think?

I would not backport it.

Thanks @sobolevn for your nice work!

@rhettinger:

I won't block any of this but view it all as unnecessary code churn (no user's life is now better). Also, when I was actively developing the C API for sets, it was convenient to have the caller and callee in the same file.

Right, in the past, we wrote C API tests differently. But for 1 or 2 years, all C API tests are being moved to test_capi. I don't fully agree, but I'm fine with this. I'm now trying to help to make tests consistent. Adding more C API tests is always a great thing.

Nikita spent significant time to enhance C API tests for the set and frozenset tests. He worked hard for that. His work was reviewed by multiple core devs and added recently to test_capi. It increases the code coverage and test coverage, it's a nice enhancement.

@rhettinger:

I won't block any of this but view it all as unnecessary code churn (no user's life is now better). Also, when I was actively developing the C API for sets, it was convenient to have the caller and callee in the same file.

Raymond, such comment can be seen as dismissive and non supportive. While you can see it as unnecessary, other core devs who reviewed and merged these C API test changes.

@rhettinger:

Also, git blame can no longer track these lines to their original commits or identify the person who made them.

It's just a normal fact of contributing to open source project, and IMO it's a great thing that code get updated by other people to make it even better. Maybe you can use your Python expertise to help contributors to get their work merged.

Most C API tests are now written in Python, using thin wrappers from _testcapi. This makes it easier to extend tests and allows you to test more corner cases. Also you get better error reports.

Perhaps in future many wrappers could be generated automatically, that would reduce human factor and make writing new tests even easier.