Python 3.1 test issue

[Terry Reedy]

On 12/16/2015 1:22 PM, George Trojan wrote:
> I installed Python 3.1 on RHEL 7.2.

According to the output below, you installed 3.5.1.  Much better than 
the years old 3.1.

> The command make test hangs (or
> takes a lot of time on test_subprocess
> [396/397] test_subprocess

This indicates that everything up to this point passed, else there would 
be '/1' or higher after '397'.

> ^C
> Test suite interrupted by signal SIGINT.

There is at least one test that normally take a couple of minutes, but 
see below.

> 5 tests omitted:
>      test___all__ test_distutils test_site test_socket test_warnings
> 381 tests OK.
> 4 tests altered the execution environment:
>      test___all__ test_distutils test_site test_warnings
> 11 tests skipped:
>      test_devpoll test_kqueue test_msilib test_ossaudiodev
>      test_startfile test_tix test_tk test_ttk_guionly test_winreg
>      test_winsound test_zipfile64
> make: *** [test] Error 1
>
> CPU was at 100% all the time for process
>
> gtrojan  15758  8907 94 17:29 pts/6 00:06:47
> /home/gtrojan/Downloads/Python-3.5.1/python -R -bb -E -Wdefault
> -Werror::BytesWarning -X faulthandler -m test.regrtest --slaveargs

Running 'python -m test -h' displays a long help messages. ('-m test' 
abbreviates '-m test.regrtest' on 3.x.) Option '--slaveargs ARGS' is 
listed without anything said about the meaning of ARGS.  I reformatted 
the ARGS list to make it more readable.

> [["test_socket", 0, false],

This appears to pass arguments to a specific test, test_socket. I would 
guess this is done by setting sys.argv. This is the first I knew about 
this.  What follows of a dict of options.  Most could have been set with 
normal --option flags.  Most are the defaults.

 >  {"huntrleaks": false,
 >   "match_tests": null,
 >   "failfast": false,
 >   "output_on_failure": false,
 >   "use_resources":
>     ["curses", "network", "decimal", "cpu", "subprocess", "urlfetch"],
>   "pgo": false,
 >   "timeout": null
 >  }
 > ]

The relevant non-default is 'use_resources'.  In particular, 'cpu' runs 
'certain CPU-heavy tests', and 'subprocess' runs all subprocess tests. 
I ran both 'python -m test -usubprocess test_subprocess' and
'python -m test -ucpu -usubprocess test_subprocess
and both took about the same time and less than a minute.

The only thing that puzzles me is that I don't see '"randomize": true' 
in the dict above, but test_subprocess is 317 in the default 
alphabetical order, not 396.

You might try re-running with defaults: python -m test.

-- 
Terry Jan Reedy