Cannot launch pytest due to existence of __pydevd_ret_val_dict in enum

[mneilly]

Environment data

• VS Code version: 1.43.2
• Extension version (available under the Extensions sidebar): 2020.3.71659
• OS and version: Debian 10 (vscode gui) and CentOS 7.5.1804 (remote docker container)
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.8 (CentOS 7.5.1804)
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
• Relevant/affected Python packages and their versions: pytest 5.2.0
• Relevant/affected Python-related VS Code extensions and their versions: Remote - SSH 0.51.0

Expected behaviour

I am trying to run pytest in a remote docker container via the Remote - SSH extension. I expect the test to run in both the terminal and via the debugger.

Actual behaviour

I can run the test in the terminal and it passes but when running it via the debugger it fails while trying to import pytest because enum.py can't process __pydevd_ret_val_dict as one of the members of the ExitCode enum.

Steps to reproduce:

The following 'test' runs successfully in the terminal but fails when running under the debugger with the show launch.json.

foo.py:

import unittest

class TestFoo(unittest.TestCase):
    def test_foo(self):
        """MWE"""
        return True

launch.json:

{
    "configurations": [
        {
            "name": "Python: Current PyTest File",
            "type": "python",
            "request": "launch",
            "module": "pytest",
            "console": "integratedTerminal",
            "stopOnEntry": true,
            "args": [
                "-s",
                "--verbose",
                "${file}"
            ],
            "justMyCode": false
        }
    ]
}

Logs

When running from the integrated terminal the test passes:

mneilly@Docker:/local/mneilly/foo$ python3 -m pytest -s --verbose /local/mneilly/foo/foo.py
========================================================================================================= test session starts =========================================================================================================
platform linux -- Python 3.6.8, pytest-5.2.0, py-1.8.1, pluggy-0.13.1 -- /usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-3.10.0-957.el7.x86_64-x86_64-with-centos-7.5.1804-Core', 'Packages': {'pytest': '5.2.0', 'py': '1.8.1', 'pluggy': '0.13.1'}, 'Plugins': {'forked': '1.1.3', 'html': '2.0.0', 'metadata': '1.8.0', 'xdist': '1.30.0'}}
rootdir: /local/mneilly/foo
plugins: forked-1.1.3, html-2.0.0, metadata-1.8.0, xdist-1.30.0
collected 1 item                                                                                                                                                                                                                      

foo.py::TestFoo::test_foo PASSED

========================================================================================================== 1 passed in 0.03s ==========================================================================================================

But when launching with the shown launch.json it fails as follows:

mneilly@Docker:/local/mneilly/foo$  env DEBUGPY_LAUNCHER_PORT=34608 /usr/bin/python3 /eng/mneilly/.vscode-server/extensions/ms-python.python-2020.3.71659/pythonFiles/lib/python/debugpy/no_wheels/debugpy/launcher -m pytest -s --verbose /local/mneilly/foo/foo.py 
Traceback (most recent call last):
  File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/eng/mneilly/.vscode-server/extensions/ms-python.python-2020.3.71659/pythonFiles/lib/python/debugpy/no_wheels/debugpy/__main__.py", line 45, in <module>
    cli.main()
  File "/eng/mneilly/.vscode-server/extensions/ms-python.python-2020.3.71659/pythonFiles/lib/python/debugpy/no_wheels/debugpy/../debugpy/server/cli.py", line 429, in main
    run()
  File "/eng/mneilly/.vscode-server/extensions/ms-python.python-2020.3.71659/pythonFiles/lib/python/debugpy/no_wheels/debugpy/../debugpy/server/cli.py", line 316, in run_module
    run_module_as_main(target, alter_argv=True)
  File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.6/site-packages/pytest.py", line 17, in <module>
    from _pytest.main import ExitCode
  File "/usr/local/lib/python3.6/site-packages/_pytest/main.py", line 21, in <module>
    class ExitCode(enum.IntEnum):
  File "/usr/lib64/python3.6/enum.py", line 201, in __new__
    enum_member = __new__(enum_class, *args)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'dict'
mneilly@Docker:/local/mneilly/foo$ cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core)

The debugger shows that the dict being complained about is __pydevd_ret_val_dict:

[int19h]

This can happen if you stepped through or over the class definition, and it contained function calls. The debugger uses a dummy local variable to capture function returned values, so that it can show them in Variables after the step completes. In this case, the dummy local ends up inside a class, and consequently becomes a class member.

[int19h]

@fabioz, for a very simple repro of the underlying issue:

def foo():
    return "foo"

class Foo(object):
    foo()

print(dir(Foo))

Set breakpoint on class or foo(), and step over the call, then observe printed output - it shows that __pydevd_ret_val_dict is a member.

I'm not sure what we can do about this, though. At the time the step was happening, there's no class yet - it's just a local frame. I'm not sure it's even possible to determine that it'll be used to build a class once it exits.

[int19h]

@mneilly As a workaround, try setting "showReturnValue":false in your launch.json.

[fabioz]

I'll take a look at that (maybe we can find a different way to store that variable).

[mneilly]

Thanks @int19h, that does allow me to work around the problem and debug the code of interest.

[fabioz]

I haven't actually found a better place to put __pydevd_ret_val_dict (there's really nothing that tracks the frame lifecycle well enough to use).

Still, seeing the actual use case, the problem here is caused by a combination of stopOnEntry:true and showReturnValue:true and this shouldn't really happen (it means that we're computing and setting return values on places where they'll never be seen because we won't actually stop on those frames), so, I'm going to do a fix for that (a user could still bump into that problem if he manually steps over the class creation as @int19h mentioned, but this shouldn't be a problem with stopOnEntry/showReturnValue when frames are being traced for the return value when they shouldn't even be traced, which was the original report).