> 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.