classification
Title: Run test suite from IDLE idlelib.run subprocess
Type: enhancement Stage: resolved
Components: IDLE, Tests Versions: Python 3.7, Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: haypo, serhiy.storchaka, terry.reedy
Priority: normal Keywords: patch

Created on 2015-11-09 08:04 by terry.reedy, last changed 2017-10-15 03:32 by terry.reedy. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 3962 merged haypo, 2017-10-12 09:42
PR 3987 merged python-dev, 2017-10-13 19:59
PR 4000 merged terry.reedy, 2017-10-15 00:57
PR 4001 merged terry.reedy, 2017-10-15 01:36
Messages (12)
msg254371 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-11-09 08:04
This issue proposes stress testing idlelib.run by running code that already reports whether results are as expected or not -- the test_suite.  Since this one test will take at least as long as the test suite, and will probably need human intervention anyway, it would not be part of test_idle, but would be run separately manually, like htest.

IDLE runs user code in a user process started with subprocess.POpen(executable + 'path/to/idlelib/run.py' + args + user_code_path) (with user_code_path omitted for shell restarts).  When run from the editor, the intent is to imitate 'python -i user_code_path'.

On python list, someone reported that running a program using pyqt5 (and qt5) hung on exit while running with python3 (on Ubuntu, no -i) worked.  I have asked for more details, including whether it works with -i included.  In the meanwhile, I wondered ...

While the run module might not be able to run programs with certain 3rd party imports, can it at least run programs restricted to stdlib imports and well enough behaved to run with python -i.  (A programs that, for instance, disables standard i/o streams would fail both in IDLE and with python.)  A test would be to at least run all stdlib tests, with the same result, as run otherwise on the same system.  The tests should be run in the user process itself and not in additional processes.  They could be run either all in one process or each in a new run process.

If successful, I will put code and instructions in a new idlelib/idle_test/rtest.py/txt.
msg269094 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-22 23:50
The premise of the issue is this: if IDLE is started with 'pythonx', then running 'filex' from a IDLE editor is equivalent to running "python x -i filex" at a command line.  For instance, loading test.__main__ into an editor and running should give the same result as 
f:/python/dev> 36\pcbuild\win32\python_d.exe -i 36\Lib\test.__main__

However, 
Traceback (most recent call last):
  File "F:\Python\dev\36\Lib\test\__main__.py", line 2, in <module>
    main()
  File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 508, in main
    Regrtest().main(tests=tests, **kwargs)
  File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 446, in main
    self._main(tests, kwargs)
  File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 458, in _main
    setup_tests(self.ns)
  File "F:\Python\dev\36\lib\test\libregrtest\setup.py", line 18, in setup_tests
    faulthandler.enable(all_threads=True)
io.UnsupportedOperation: fileno

The pseudofile socket wrappers are not real files with a fileno.  I should take a better look as sys.stdout and _stdout (and stderr) when connected to a console,
msg304224 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2017-10-12 09:49
I proposed PR 3962 to fix a few issues in regrtest when sys.stdout and sys.stderr have to file descriptor.

I'm not sure that we should promote running tests with unusual sys.stdout and sys.stderr, since many tests fail in that case. That's why I chose to not add a NEWS entry to my PR.

For example, test_builtin hangs until you write something in IDLE, whereas no prompt is displayed. test_faulthandler fails, and much more tests. I'm not interested to support running the Python test suite in IDLE.

Maybe we should even detect that we are running in IDLE and fail with an helpful error message like :

"Running the Python test suite inside IDLE is not supported. Run the test suite in a terminal."

At least, write a warning in UPPERCASE if sys.stdout or sys.stderr have no file descriptor?
msg304227 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-10-12 10:25
I think it would be nice to make testing so flexible as possible. This would help to get rid of unintended assumptions. If some tests are failed on IDLE I would prefer to fix or skip only these tests.
msg304230 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2017-10-12 13:12
Serhiy: "If some tests are failed on IDLE I would prefer to fix or skip only these tests."

Ok, go ahead. There are many failing tests :-)
msg304354 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2017-10-13 19:59
New changeset ccef823939d4ef602f2d8d13d0bfec29eda597a5 by Victor Stinner in branch 'master':
bpo-25588: Fix regrtest when run inside IDLE (#3962)
https://github.com/python/cpython/commit/ccef823939d4ef602f2d8d13d0bfec29eda597a5
msg304357 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2017-10-13 20:42
New changeset 6234e9068332f61f935cf13fa5b1a924a99c28b2 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-25588: Fix regrtest when run inside IDLE (GH-3962) (#3987)
https://github.com/python/cpython/commit/6234e9068332f61f935cf13fa5b1a924a99c28b2
msg304407 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-10-15 01:26
As I reported on related #31761, importing autotest on Windows 10 has 3 errors with Python's shell and 4 with IDLE's, with two of those the same as the python shell failures.

IDLE can be detected in at least two ways.
>>> import sys; 'idlelib.run' in sys.modules
True
>>> type(sys.stdout).__name__ == 'PseudoOutputFile'
True

'test.autotest' in sys.modules" would detect that test.autotest is being run, whether in a Python or IDLE shell.

Running test.__main__ from an editor results in screwy behavior.  Running just 'import test.autotest' instead gives the same result.  I expected at least the latter to have the same result as when run in the shell.  Wrong.

First, there is an additional test failure.

0:00:12 [ 18/407] test_aifc
test test_aifc crashed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\libregrtest\runtest.py", line 163, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "F:\dev\3x\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 680, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "F:\dev\3x\lib\test\test_aifc.py", line 9, in <module>
    import aifc
  File "F:\dev\3x\lib\aifc.py", line 254, in <module>
    from chunk import Chunk
ImportError: cannot import name 'Chunk' from 'chunk' (F:\Python\mypy\chunk.py)

Next, the tests run normallu up to
:03:18 [ 77/407/1] test_concurrent_futures

Then, while running test_configparser, the user process crashes, IDLE restarts a new user process, and the test suite restarts (in the IDLE process?) from the beginning, sending output to the console, not IDLE, and running each test 5 times.  This all is repeatable.  The following is the initial part of the console output.

== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== Windows-10-10.0.14393-SP0 little-endian
== cwd: F:\dev\3x\build\test_python_2056
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== cwd: F:\dev\3x\build\test_python_6020
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
Run tests sequentially
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== cwd: F:\dev\3x\build\test_python_272
0:00:00 [  1/407] test_grammar
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
Run tests sequentially
== cwd: F:\dev\3x\build\test_python_7396
0:00:00 [  1/407] test_grammar
== Windows-10-10.0.14393-SP0 little-endian
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== cwd: F:\dev\3x\build\test_python_13476
Run tests sequentially
== CPU count: 12
0:00:00 [  1/407] test_grammar
== encodings: locale=cp1252, FS=utf-8
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
Run tests sequentially
0:00:00 [  1/407] test_grammar
0:00:00 [  1/407] test_grammar
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
[and so on]

I said 'crash' because the run process catches SystemExit.
>>> raise SystemExit
>>> 
I have ocassionally encountered unexpected restarts before, but never, that I remember, so easily repeatable.
msg304408 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-10-15 01:29
The README patch will finish this issue.  Fixing individual failures and investigating the crash will be new issues.
msg304409 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-10-15 01:31
New changeset 620f70eed615efde35517d7ae86354de3b2a0d03 by Terry Jan Reedy in branch 'master':
bpo-25588: Document autotest in idle_test/README.txt. (#4000)
https://github.com/python/cpython/commit/620f70eed615efde35517d7ae86354de3b2a0d03
msg304410 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-10-15 03:17
New changeset 0fee56c86344386bde8486ab803f564cb8a5203b by Terry Jan Reedy in branch '3.6':
[3.6] bpo-25588: Document autotest in idle_test/README.txt. (GH-4000) (#4001)
https://github.com/python/cpython/commit/0fee56c86344386bde8486ab803f564cb8a5203b
msg304411 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-10-15 03:31
Running the file containing 'import test.autotest' directly with python gives the test_aifc failure and the same bizarre behavior after test_concurrent_futures.  Testing restarts apparently in 5 parallel threads or processes.  The lines of output are the same though interleaved slightly differently.  The only difference is that the number in the 5 build/test_python_nnnn working directories are different. So, not an IDLE bug.
History
Date User Action Args
2017-10-15 03:32:00terry.reedysetstatus: open -> closed
resolution: fixed
messages: + msg304411

stage: patch review -> resolved
2017-10-15 03:17:00terry.reedysetmessages: + msg304410
2017-10-15 01:36:34terry.reedysetstage: commit review -> patch review
pull_requests: + pull_request3974
2017-10-15 01:31:17terry.reedysetmessages: + msg304409
2017-10-15 01:29:26terry.reedysetmessages: + msg304408
2017-10-15 01:26:52terry.reedysetstage: patch review -> commit review
messages: + msg304407
versions: + Python 3.7
2017-10-15 00:57:32terry.reedysetpull_requests: + pull_request3973
2017-10-13 20:42:29hayposetmessages: + msg304357
2017-10-13 19:59:25python-devsetpull_requests: + pull_request3963
2017-10-13 19:59:15hayposetmessages: + msg304354
2017-10-12 13:12:09hayposetmessages: + msg304230
2017-10-12 10:25:12serhiy.storchakasetmessages: + msg304227
2017-10-12 09:49:43hayposetnosy: + haypo, serhiy.storchaka
messages: + msg304224
2017-10-12 09:42:37hayposetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request3940
2016-06-22 23:51:27terry.reedysetversions: - Python 2.7, Python 3.4, Python 3.5
2016-06-22 23:50:10terry.reedysetmessages: + msg269094
2015-11-09 08:04:43terry.reedycreate