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.