Ezio Melotti added the comment: > Umm, WTF? You're really asking me to justify the basic software > engineering principle that modularity is good,
I'm aware of the principle -- what I'm asking is what practical advantages this will bring (practicality beats purity). > and wanting to dump everything in one file is one of the classic signs > that your architectural design is non-existent and you have completely > failed to adequately decompose your problem into smaller ones? As I see it, test.support is a module containing miscellaneous helper functions to be used in the tests. Therefore, if I'm looking for an helper function (like assert_python*()), I could just open the file and find it there. This is especially true for *generic* helper functions, like assert_python* (not widely used, see #9517) and temp_dir (duplicated in support.py, see #15376). Both these issues were probably caused by the fact that people didn't know about script_helper.py and ended up implementing their own versions of the functions either in the test files or in support.py. Something similar happened with requires_zlib (and possibly a few others) too -- it was defined in several test modules before being moved to support.py. Having several modules doesn't solve the problem of discoverability -- it actually make it worse by adding another level of indirection (find what files do you have and which one is the right one -> find what you are looking for in the right file). I often look at the code from hg.python.org, and ctrl+f there clearly covers only one file. Similarly inspecting/grepping a single file is easier than doing it for multiple files, especially if you don't know what the other files are. If people are not trying to find a specific function, but rather want an overview of the helper test functions, we could (and should) document them like we did with Doc/library/test.rst and have sections there. For example if I `ls` Lib/test/support/ and see a script_helper.py file, I could hardly guess that it contains functions to run python in a subprocress. This could be easily explained in the doc. That said, I should mention that 1) I'm not sure how many other helper modules there are around, how big they are, and how well things are already divided; 2) I don't know the structure that you want to use for the package. If you are just grouping the existing helper modules in a package and if the namespace is kept flat (so that we don't end up with test.support.whatever.TESTFN), then I agree that it's an improvement. If you are planning to further split support.py, then I'm -1. > "Huge source files are inherently bad because they > provide no hint as to the modular breakdown I can't think off the top of my head of a sensible breakdown for support.py. I can see that the assert/kill/spawn/python functions are all related, but the current module division seems to me quite arbitrary. Why import(_fresh)_module and related functions are not on their own module even if they have more code than all the assert/kill/spawn_python functions? Should all the skip/require decorators in support.py get their own module? What about the context manages like run_with_locale, temp_dir, temp_umask, EnvironmentVarGuard, etc.? Why script_helper contains helper functions to run python in a subprocess and also helper functions for scripts? > If the objections were "I think this particular proposed > breakdown is bad" If you suggest a breakdown I can provide better objections, however I think it's already broken down enough (and maybe even too much). > I already did, that thread 'tis a large part of why > I'm somewhat irritable in relation to this topic today. Same here, just in the opposite directions ;) P.S. incidentally the other day someone asked me where unittest.main was defined because he couldn't find it using "Find in files". We tried looking in __main__.py and __init__.py for "def main" and it wasn't there, but we noticed a "from .main import TestProgram, main". So we looked in main.py for a "def main" and still couldn't find it, so we looked for just "main". Eventually we found a "main = TestProgram" at the very bottom of main.py. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15494> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
