Python debugger changes __file__

[adusamr]

Type: Bug

Behaviour

Steps to reproduce:

1. Make launch.json be like

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "script.py",
            "cwd": "<the parent directory of srcipt.py>"
            "console": "integratedTerminal",
            "justMyCode": true,
        }
    ]
}

and script.py be

print(__file__)

2. When I run the script.py with debugger (by F5) the __file__ is "script.py".
   When I run the script.py without debugger (by ctrl-F5) the __file__ is the absolute path of script.py.

According to https://stackoverflow.com/questions/7116889/is-module-file-attribute-absolute-or-relative, __file__ should be absolute path, because my python version is 3.10.

This happens when "program" of launch.json is relative path.
When "program" is absolute path, the launched script.py's __file__ is absolute path, but if I call subprocess.run(["python", "script2.py"]) in script.py, called script2.py's __file__ becomes "script2.py"

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.10.12
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
• Value of the python.languageServer setting: Pylance

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings

languageServer: "Pylance"

Extension version: 2023.22.1
VS Code version: Code 1.85.2 (8b3775030ed1a69b13e4f4c628c612102e30a681, 2024-01-18T06:40:10.514Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux x64 5.15.133.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.133.1-microsoft-standard-WSL2

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 x 3600)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	31.92GB (21.33GB free)
Process Argv	--crash-reporter-id d0837e9f-f8e1-46b8-b5ab-112cca56ee24
Screen Reader	no
VM	0%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 5.15.133.1-microsoft-standard-WSL2
CPUs	Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 x 3600)
Memory (System)	19.54GB (17.84GB free)
VM	0%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 5.15.133.1-microsoft-standard-WSL2
CPUs	Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 x 3600)
Memory (System)	19.54GB (17.84GB free)
VM	0%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes516:30244333
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30933248
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019acf:30933242

[int19h]

We use runpy.run_path to approximate what Python does in this scenario. It appears that it doesn't reflect the change in Python CLI behavior, though, so we'll need to handle path conversion on our own. Thanks for catching this!

[tjni]

I was bitten by this today. Is this on someone's radar? If not, any pointers to where in the code this should be fixed – I can take a crack at it.

[rchiodo]

Sorry not on our radar at the moment. If I were to try and fix it, I'd start by looking where __file__ is implemented in CPython and see how we might override that behavior. Like @int19h said, we don't run your program exactly the same way as running it from the CLI, so we'd likely have to monkey patch the behavior of __file__.

[gramster]

The underlying issue may be in pydevd, not debugpy? As that is where the run_path function lives.

[rchiodo]

The underlying issue may be in pydevd, not debugpy? As that is where the run_path function lives.

Fabio hasn't been doing much lately, so under pydevd usually means we have to fix it ourselves, if we want a fix.