Attached is a quick-and-dirty script that converts a large chunk of the test suite away from support.run_unittest and test_main to unittest test discovery and unittest.main.  Several files are marked as 'do not touch' due to various issues that the script can't easily detect, many others are not touched due to issues that the script can detect but can't deal with on its own.  Tests that can be changed are changed directly, console output is a huge listing of test files checked and what was done with them, followed by a summary of what tests were not touched for what reason, and a list of changed tests is output in 'changed_tests.txt'.

Here's a diff against 3.4 produced by the script.  Warning: it's rather large.

$ hg diff --stat
[...]
 162 files changed, 199 insertions(+), 942 deletions(-)

You might add a brief description of why this is good idea, or link to such a discussion. 

I am +1 on the idea, but a pydev discussion might be needed.

How did you test the patch?  I don't think that passing the same tests in non-verbose mode is good enough, as an empty test is a pass.  What would be convincing is an automated comparison of verbose output before and after that showed that everything run before is run after. There might be more after if something was omitted from a run_unittest call. That past actuality and current possibility is part of the reason for the change.

Timing: I think applying this too close to a release might be a bad idea. I am thinking more of human mental adjustments (and the need to refresh some patches) rather than likely technical issues. If this were approved when 3.4.2 were expected within a month, say, I would wait until it were released.

There are a couple things I really like about this idea:

* In the past, we've had cases of TestXXX classes being omitted, so chunks of the test suite weren't being run.  You patch will fix that and let test discovery "just work".

* The code is shorter, more idiomatic, and matches the way most users of unittest run their code.

I've added a number of stakeholders to the nosy list so they will have a chance to chime in.

I haven't reviewed the patch in detail, but I've had a scan through and it looks *great*. A quick and dirty check that it's "correct" is to compare the number of tests run before and after the patch - and if the numbers differ verifying that it's for good reasons (i.e. only *extra* tests being run and none being skipped / missed).

If that's the case I'd be strongly in favour of applying.

+1 from me (after verification), which should probably go without saying since I'm the one that started this ball rolling by making regrtest work with unittest discovery :)

I think the potential disruption to existing patches and any forward porting issues (I expect them to be minor if they occur) are worth it just for the fact that we won't be missing tests via incorrect or forgotten updates to the list of tests to run.

Thanks for working on this, Zach, as well as your previous work that set up for this.

Some abstract test classes now are included in testing:

Lib/test/test_calendar.py: MonthCalendarTestCase
Lib/test/test_csv.py: TestCsvBase
Lib/test/test_funcattrs.py: FuncAttrsTest
Lib/test/test_sys_setprofile.py: TestCaseBase
Lib/test/test_telnetlib.py: ExpectAndReadTestCase
Lib/test/test_thread.py: BasicThreadTest
Lib/test/test_unicodedata.py: UnicodeDatabaseTest
(and may be other)

Lib/test/test_enumerate.py, Lib/test/test_functools.py, Lib/test/test_list.py, 
Lib/test/test_peepholer.py, Lib/test/test_sort.py verified reference counting 
in verbose mode. Now this code is deleted.

Those should be turned into mixins, or someone could implement issue 14534.

I compared tests output with and without patch and noticed only one significant 
difference.

ForkWait is imported in Lib/test/test_wait3.py, Lib/test/test_wait4.py and 
Lib/test/test_fork1.py and now it is executed 4 times. Either this class 
should be turned into mixing, or it shouldn't be imported (import a module 
instead).

@Terry: This is part of the ongoing effort of issues #16748 and #10967 (and possibly others).  My ultimate goal along those lines is to eradicate support.run_unittest, and this is a step in that direction.

I think there's enough support here to skip python-dev :).

My testing has been limited (by time, mostly) to just a non-verbose run to confirm that nothing errors after the patch.  It seems Serhiy has tested more extensively, though.

@Raymond: May I ask why you removed 3.4 from versions?  Most of the changes like this in individual modules have been made on all open 3.x branches (most that I've been involved in were in the 3.3 maintenance period).  I don't feel strongly enough about making sure this is in 3.4 to argue if you have a good reason, though.

@Serhiy: Thanks for testing this!  The reference counting in individual modules has been dying a slow death, long ago replaced by regrtest's -R option.  For the modules with base classes included in testing, I'm inclined to either leave them as patched (since they don't actually add any tests and their overhead is minimal) or remove them from the patch and deal with them in a new issue; I'm leaning toward the first option.  For the wait tests, I would rather remove them from the patch and deal with them separately.

@Terry, Raymond, Michael, David, and Serhiy: thanks for the support!

>  My ultimate goal along those lines is to eradicate
> support.run_unittest, and this is a step in that direction.
>
>I think there's enough support here to skip python-dev :).

Not really.  There is support here for using unittest.main() whereever it fits and cleans-up the code.  That is not the same as saying we can eliminate support.run_unittest().  That is likely a more thorny issue and may affect users outside the standard library.

> @Raymond: May I ask why you removed 3.4 from versions?

Because we don't backport this sort of change.  The ship for version 3.4 has sailed.  There's no point in rewriting history for something that isn't a bug fix, documentation fix, or performance regression.  Also, who knows who is already relying on the current setup and would have their code broken in the next micro-release.   (Second law of time travel: the past is infinitely fragile and the future is infinitely mallable)

Raymond Hettinger added the comment:
>>I think there's enough support here to skip python-dev :).
>
> Not really.  There is support here for using unittest.main()
> whereever it fits and cleans-up the code.  That is not the same as
> saying we can eliminate support.run_unittest().  That is likely a
> more thorny issue and may affect users outside the standard library.

Apologies, my remark was in response to Terry's suggestion that this particular issue should go through python-dev, and was only meant to apply to this issue, not the elimination of run_unittest.  If/when the day that is possible comes, I will consult python-dev as appropriate.

>> @Raymond: May I ask why you removed 3.4 from versions?
>
> Because we don't backport this sort of change.  The ship for version
> 3.4 has sailed.  There's no point in rewriting history for something
> that isn't a bug fix, documentation fix, or performance regression.
> Also, who knows who is already relying on the current setup and would
> have their code broken in the next micro-release.   (Second law of
> time travel: the past is infinitely fragile and the future is
> infinitely mallable)

While I appreciate that, the note at the top of https://docs.python.org/3/library/test.html gives me the impression that anyone using code from the test package should either know better or expect their code to break any time they upgrade.  That is, that the test package is exempt from the usual backward compatibility restrictions.

I would rather apply to both 3.4 and default for ease of future merges, but again, since the changes are so small (on a per-module level), I won't fight for it.

New changeset 3aec776fc796 by Zachary Ware in branch 'default':
Issue #21741: Update 147 test modules to use test discovery.
https://hg.python.org/cpython/rev/3aec776fc796