Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

All commit authors signed the Contributor License Agreement.

it's my first pr here so i don't know much about the NEWS entry, if it's not a problem can anyone tell me if i do need to add any NEWS entry ?

Documentation build overview

📚 cpython-previews | 🛠️ Build #33432191 | 📁 Comparing 8b77d9d against main (423ae0f)

  🔍 Preview build  

it's my first pr here so i don't know much about the NEWS entry, if it's not a problem can anyone tell me if i do need to add any NEWS entry ?

thanks for the PR, as per my thought yes, this will need NEWS entry but you can wait for the review and then you can add NEWS entry ( to get 100 % sure 😀)

i have another question for the Android test failure should i update the test_posix.py ? to do something like if support.is_android and os.getuid() != 0: so it will not failed on PermissionError ? or should i need to update something on my patch so the existing test pass

why did the Tests / Sanitizers / TSan (free-threading) (pull_request) failed i don't get it ?

We can see that the cause of one of the test failures probably is that the Python test suite has interpreted the unblocking of setresuid() as an indication that it should be usable as non-root user, even though we want to use it as root user and continue to show an error for non-root users;

I would say that yes, the test should probably be modified to check for Android platform, and in the case of Android platform, only test that function if the test is running as root user;

however, what I find concerning is that the CI here only produced a failure for x86_64, and not for aarch64, even though in my own separate test, both x86_64 and aarch64 architectures of Android should be returning the same result from the same function:

I wonder if that suggests there is a deeper problem with the tests or an inconsistency somewhere in the test implementation between x86_64 and aarch64.

@robertkirkman yes, let see what others are saying about this . I still didn't get any other comment from any of the core maintainers