VSCode's "Run and Debug" or the Debugger itself seems to break Python code related to Protocols and isinstance checks

[smbache]

Environment data

• VS Code version: 1.59, 1.60
• Extension version (available under the Extensions sidebar): v2021.10.1336267007
• OS and version: MacOS 11.5.2, Ubuntu 20.04
• Python version (& distribution if applicable, e.g. Anaconda): 3.8, 3.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: N/A
• Relevant/affected Python-related VS Code extensions and their versions: N/A
• Value of the python.languageServer setting: default

Expected behaviour

To not error

Actual behaviour

Error raised when using "Debug and Run". No errors when running normally.

Steps to reproduce:

This is an issue I can only reproduce by running the code below using "Run and Debug" from vscode, and it relates to the Protocol feature introduced in Python 3.8, and using the debugger in vscode. I am not sure this is the right place to raise the issue, but could not think of a better place. I could not reproduce it with debugpy alone, so posting it here, rather than in the debugpy issues.

Consider the following simplified example:

from typing import Any, Protocol, runtime_checkable

@runtime_checkable
class Proto(Protocol):
    some_attr: int

class Foo(object):
    def __getattribute__(self, attr: str) -> Any:
        print(f"I have been summoned to deliver {attr}")
        result = object.__getattribute__(self, attr)

        print(f"I am delivering {result}")
        return result

if __name__ == "__main__":
    isinstance(Foo(), Proto)

Running this with "Run and Debug" gives this error

However, running the file normally exits normally and gives the output:

I have been summoned to deliver some_attr
I have been summoned to deliver __class__
I am delivering <class '__main__.Foo'>

The isinstance call silently handles the error that occurs when accessing the attribute some_attr on an object on which it does not exist, which is also seen from the output where the second print statement is not reached in both invocations of __getatttribute__. Exactly what happens when the "Debug and Run" approach to execution is used is unclear to me, but it seems to break otherwise working code.

[hgarridoco]

Same error here. If I run without debuging works fine, but I need to debug!

[int19h]

The exception itself has always been there - you're seeing it now because now it gets displayed where it previously wasn't, but it's not actually fatal (i.e. you can press F5 and it'll continue running normally).

To prevent debugger from breaking on this exception, uncheck "User-uncaught exceptions" in the Breakpoints list in the Debug pane. We'll change the default for this checkbox in the next release of debugpy.

[anhvu-sg]

The same problem, maybe it's related to the latest update, I just turn off my machine last night and this morning it doesn't work

File: "/Users/osx/.pyenv/versions/3.7.8/lib/python3.7/_collections_abc.py", line 662, in get return default File: "/Users/osx/.vscode/extensions/ms-python.python-2021.10.1336267007/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_trace_dispatch_regular.py", line 204, in trace_dispatch return thread_trace_func(frame, event, arg) File: "/Users/osx/.vscode/extensions/ms-python.python-2021.10.1336267007/pythonFiles/lib/python/debugpy/_vendored/pydevd/pydevd.py", line 1068, in enable_tracing pydevd_tracing.set_trace_to_threads(thread_trace_func) File: "/Users/osx/.vscode/extensions/ms-python.python-2021.10.1336267007/pythonFiles/lib/python/debugpy/_vendored/pydevd/pydevd_tracing.py", line 90, in SetTrace return File: "/Users/osx/.vscode/extensions/ms-python.python-2021.10.1336267007/pythonFiles/lib/python/debugpy/_vendored/pydevd/pydevd_tracing.py", line 374, in set_trace_to_threads return ret

Note that:

• Without debugging -> works fine
• Debugging -> fail

[fabioz]

This is a duplicate of #751

Please uncheck User Uncaught Exceptions to avoid this.