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
Refactor package creation support code into a common location #59608
Comments
This issue addresses the "file creation" portion of bpo-15376, which is to refactor the walk_package support code in test_runpy into a common location. |
Attaching patch. |
It occurs to me that the filecmp/dircmp tests in Lib/test/test_filecmp.py would also benefit from code like this (i.e. being able to create a nested directory of files in one or two lines). And perhaps elsewhere in the tests. This is an argument for slightly generalizing the test support API in the uploaded patch from creating modules/packages to creating files/directories. A convenience wrapper for packages could still be included that includes an __init__.py in the calls to the underlying directory code. |
Lib/test/test_import.py also contains test code that would benefit from this (see for example bpo-15425). (Though not all files need to be refactored in a single issue.) |
Please let's not have something called test.supportlib in addition to test.support. If test.support grows too large we can turn it into a package. |
I feel like it is already too large (it is over 1750 lines), and I did not want to create a third sibling test support module (there is also test/script_helper.py that overlaps with test.support). Do you think that the community would be open to refactoring test.support into a package for Python 3.3? This was meant to assist in increasing test coverage for Python 3.3 bugs. |
That's too late for 3.3, IMO. Whether or not test.support is too large |
At this point, would you advise me to add even more to the existing hodge podge, or to create a third sibling test support module? My patch adds closely related test support functionality. Incidentally, this discussion relates to the point I was getting at in the python-dev thread in the past couple days about how restrictions on refactoring test support code for maintenance releases can affect the quality of our test code. I am still struggling with how to approach that. |
I don't mind refactoring test support routines in maintenance release. I As for the way forward, I see three possibilites:
My personal preference would be for 1) or 3). But whatever we choose, we |
Thanks for your thoughts. For the purposes of this patch, I will change to putting the new support functionality in test.support. Going forward, if we could do some of the refactoring for 3.3.1, that would be great. :) I worry that the third option may make things worse because it would become less obvious where all of the different test support functionality is located. Are you opposed to (2), or is it simply less favorable? The transition to (2) could be a gradual one beginning with two or even one module inside the package. |
Less favorable, because it produces longer import strings |
This can be addressed by exposing the API in __init__.py though (as does, say, the unittest package), no? |
Le dimanche 29 juillet 2012 à 17:00 +0000, Chris Jerdonek a écrit :
Yes, that's right. |
Discoverability is definitely a problem - part of that is a docs issue, since test.support is currently the only one mentioned in the prose docs. One advantage to moving to a support subpackage is that we can lose the "helper" suffix from the names, while still allowing thematic divisions. So, for example, we could have # support.py -> support/__init__.py
import test.support
# script_helper.py -> support/scripts.py
import test.support.scripts
# Other possible additions
import test.support.imports
import test.support.network Even without updating the prose docs, this would help discoverability a lot by having a much smaller directory listing to scan for useful support code. At the moment the general purpose helper modules are mixed in with the tests I agree with Antoine that we're probably better off handling this as a refactor post-release at this point, though. I'd hoped to have the time to devote to it beforehand, but there's user facing stuff that's higher priority right now. |
Sounds good. Later today I will create an issue to move test/support.py into a test.support subpackage post-release. We can continue the discussion of how to organize it there. |
I created bpo-15494 for this. |
Attaching an updated patch. Changes include:
|
updated patch to apply on top of patch from bpo-15494 |
As noted in bpo-18576 and bpo-18578, I'd like for these relocation patches to include the addition of documentation for the submodule in Doc/library/test.rst |
Also, now that test.support is a subpackage, the helper should be a submodule of that (test.support.package_helper) rather than directly in the test directory. |
I took a look at this last night, and found the combination of moving stuff around *and* refactoring it at the same time was too hard to review. So, once the PEP-451 changes for runpy are done, I think it would make more sense to tackle this as at least three patches:
3+. Refactor other test modules to use the now shared API (there may be some pkg related functionality to move out of script_helper as well). |
This issue is 7 years old and has patches: it is no newcomer friendly, I remove the "easy" keyword. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: