-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-38223: Reorganize test_shutil. #16281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Group tests for specific functions and groups of related functions into separate classes. * Clean up creating and cleaning up temporary directories. * Simplify and make more robust monkey patching of shutil.open.
Why would this be backported to maintenance releases? |
This will help a much in backporting future tests. It is easier and safer to backport large but straightforward changes which will allow future backports to be made automatically by @miss-islington or manually with simple conflicts than backport all future changes only manually and with large conflicts and large risk of errors. It is common practice for large test changes. I am not sure about 2.7. If the code is too different (because |
It's good that you want to improve the code base but why would we be doing future backporting of tests to maintenance branches nearing the end of their bugfix periods? We should be minimizing the number and scope of changes going into 3.7 and especially 2.7 at this point in their cycles. And, in any case, large-scale refactoring of code, be it in library modules or tests, is out-of-scope for maintenance branches. The devguide is clear: "The only changes allowed to occur in a maintenance branch without debate are bug fixes." As releases mature in their bugfix phase, our downstream users expect us to not break anything so that they can painlessly as possible update to the latest maintenance release, and that includes tests which some users run as part of their testing programs. At this point in their cycles, we should be focused on security fixes, regressions within a release cycle, bugs that are still currently causing problems for users, and any changes necessary to support updates to the primary supported platforms. |
I concur it's probably not worth the backport(s), otherwise +1 on the change. |
Okay. But in past we usually backported test reorganizing changes to help future backporting of tests for bugfixes. We also backported documentation changes. We even backported such significant changes as rewriting It is not without debate. There is a debate. |
* Group tests for specific functions and groups of related functions into separate classes. * Clean up creating and cleaning up temporary directories. * Simplify and make more robust monkey patching of shutil.open.
into separate classes.
https://bugs.python.org/issue38223