Tested on Python 3.6 (default branch):

haypo@smithers$ ./python -m test test_traceback
[1/1] test_traceback
1 test OK.

haypo@smithers$ ./python Lib/test/test_traceback.py 
..........................................F...............
======================================================================
FAIL: test_walk_stack (__main__.TestStack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_traceback.py", line 684, in test_walk_stack
    self.assertGreater(len(s), 10)
AssertionError: 10 not greater than 10

----------------------------------------------------------------------
Ran 58 tests in 2.184s

FAILED (failures=1)

Put in a fix. Let me know if it looks ok.

I found a similar bug in other tests, I opened the new issue #25795.

The test was introduced by the change 73afda5a4e4c of the issue ##17911 in Python 3.6:
---
changeset:   94850:73afda5a4e4c
parent:      94848:fc0201ccbcd4
user:        Robert Collins <rbtcollins@hp.com>
date:        Thu Mar 05 12:07:57 2015 +1300
files:       Doc/library/linecache.rst Doc/library/traceback.rst Lib/linecache.py Lib/test/test_linecache.py Lib/test/test_traceback.py L
description:
Issue #17911: traceback module overhaul

Provide a way to seed the linecache for a PEP-302 module without actually
loading the code.

Provide a new object API for traceback, including the ability to not lookup
lines at all until the traceback is actually rendered, without any trace of the
original objects being kept alive.
---

I would prefer that Robert reviews the change to make sure that it's correct.

It looks like running Lib/test/test_traceback.py creates a less deeper callback, the callback has 10 frames whereas the test ensures that we have *more* than 10 frames. Output of traceback.print_traceback():
---
..........................................
  File "Lib/test/test_traceback.py", line 923, in <module>
    unittest.main()
  File "/home/haypo/prog/python/default/Lib/unittest/main.py", line 94, in __init__
    self.runTests()
  File "/home/haypo/prog/python/default/Lib/unittest/main.py", line 255, in runTests
    self.result = testRunner.run(self.test)
  File "/home/haypo/prog/python/default/Lib/unittest/runner.py", line 176, in run
    test(result)
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648, in __call__
    return self.run(*args, **kwds)
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600, in run
    testMethod()
  File "Lib/test/test_traceback.py", line 683, in test_walk_stack
    traceback.print_stack()
---

I count 11 frames, but I guess that we should exclude the latest one.

If I understood correctly, we should modify the unit test to check that we have at least *9* frames instead of 10.

I don't think that it's ok to test the *exact* number of frames, because it's highly dependent of the implementation of the unittest module. Tomorrow, the unittest module may be modified to add new calls in the call stacks... or maybe even remove some calls, but IMHO this is less likely.

---

This issue remembers me a very complex issue related to sys.setrecursionlimit(), issue #25274. I factored deeply Lib/test/regrtest.py (which even became a "library", Lib/test/libregrtest/), and with this change, I added more calls to the call stack. As a consequence, I triggered a new complex bug in how Python handles RecursionError.

At the end, I modified sys.setrecursionlimit() to raise directly a RecursionError if the new limit is too low *depending on the depth of the current call stack* ;-)

@Robert: Can you please take a look at the attached patch? Does it look good to you?

Can we just stop running the test suite directly?

python -m unittest test.test_traceback

should work fine and as quickly, ... I'd like to delete all the __main__ in the test suite as cruft TBH.

The patch would be ok if ugly, its a bit of a magic number there. What the test really should do is create a recursive function of some depth, and then introspect the result of calling the function at the bottom of that recursion.

I would use different test, not depending on outer stack depth.

@serhiy, how is that different to what I said?

Sorry, I meant different from current test and from previous patch. But it looks like what you were proposed.

Ping.

New changeset 8d150de9edba by Serhiy Storchaka in branch '3.5':
Issue #25783: Fixed test_traceback when run directly (without regrtest).
https://hg.python.org/cpython/rev/8d150de9edba

New changeset 4646b64139c9 by Serhiy Storchaka in branch '3.6':
Issue #25783: Fixed test_traceback when run directly (without regrtest).
https://hg.python.org/cpython/rev/4646b64139c9

New changeset 696851f38c93 by Serhiy Storchaka in branch 'default':
Issue #25783: Fixed test_traceback when run directly (without regrtest).
https://hg.python.org/cpython/rev/696851f38c93