__name__ in python script, when sent to interpreter is ''

[smoothdeveloper]

steps to reproduce

make a python file:

print(__name__)

open in VS Code

select the line, and send to the interpreter

expected results

it should print the file path of the script I sent the code from, if it is from a file buffer

actual results

it prints an empty string

see also, when I do the same with F# .fsx script:

printfn $"{__SOURCE_DIRECTORY__}"
printfn $"{__SOURCE_FILE__}"

It does what I want.

[brettcannon]

That's unfortunately not possible as Python sets that value, not us.

[smoothdeveloper]

@brettcannon thanks for the feedback, this is a big usability issue IMO, maybe we should keep it open and put an "blocked-upstream" tag to not mix it up with other requests?

Moreover, the line number in the stacktrace of code that causes them don't match anything in the editor, it makes it very difficult to figure anything with the code.

@gvanrossum @dsyme, I believe this makes the interpreter much less useful than it could to people writing python code:

• how would you load a file adjacent to a script? do I have to hardcode path in my script?
• how can I know which line in my script just caused an error message?

F# interpreter and how it is integrated with main editors supports this through, with the editor sending hidden directives such as :

#cd "/path/where/the/script/I/just/evaluated/a/snippet/from/"
#line 10 "file.fsx"

I belive the python interpreter could handle something similar to make it usable with same attributes I described about F# interpreter.

Please let me know if I should bring the issue to another repository / another location.

Thanks a lot!

[brettcannon]

@smoothdeveloper please don't @ mention other people not involved with this repo as that comes off as spamming others (i.e., Don has nothing to do with Python and this has nothing to do with Guido; I am a Python core developer and member of the Python steering council, so please don't loop in other people as I am fully empowered to handle this).

• how would you load a file adjacent to a script? do I have to hardcode path in my script?

No, you just have to make sure sys.path is set up appropriately for your code, and in general Python takes care of this for you.

• how can I know which line in my script just caused an error message?

Python automatically handles this.

Your bug report was about sending a single line to the REPL that's trying to print __name__, not about import failures. Import doesn't use __name__ to resolve imports anyway, so I think your concerns are premature based on your single line experiment. As such, I am not reopening this issue as I think you might be trying to extrapolate how Python imports work based on your F# knowledge which don't work the same way as Python.

If you would like help with Python itself, https://discuss.python.org/ is probably a good place to go.

[smoothdeveloper]

@brettcannon thanks for the feedback, let's not speculate how I come across to the persons I mentioned, or assume I did wrong here, thanks for specifying you are involved with the Python language itself.

No, you just have to make sure sys.path is set up appropriately for your code, and in general Python takes care of this for you.

To clarify, my use case is not to load an adjacent python file (for which I'd need to alter the sys.path, and deal with the python module system, which I agree, is different than F#), see for example:

echo a,b,c > test.csv

#test.py in same folder as test.csv
import pandas as pd
pd.read_csv("test.csv")

python3 test.py

This works fine, but if I try to evaluate the code from the same file in vscode, it fails to locate test.csv file.

>>> pd.read_csv('test.csv')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/site-packages/pandas/io/parsers/readers.py", line 912, in read_csv
   ...
FileNotFoundError: [Errno 2] No such file or directory: 'test.csv'

Notice that in the stacktrace, instead of having the location within test.py, I get File "<stdin>", line 1, in <module> which is not helpful (assuming I'm evaluating more complex code, it would be difficult to trace back the line in the editor / file itself).

Similarly, when I evaluate this:

print(os.path.abspath(os.path.curdir))

I get the equivalent of ~/.

When I execute the script from shell, I get the equivalent of pwd

As far as I understand, this is something that will end up having to be handled in this extension, by letting the interpreter know the location of submitted code, and possibly changing the working directory before submitting the code.

Note that in jupyter notebooks, it doesn't suffer from the same issue, I assume it does the operations I describe.

I'm ok opening topics on the python forum about the two issues (relative path and stack trace not showing proper location), and will look at the forum, but still have a gut feeling the extension itself will need to be adjusted, more à propos here than on the forum which touches on the language itself.

Thanks again for sharing your thoughts and guidance.

[brettcannon]

Notice that in the stacktrace, instead of having the location within test.py, I get File "<stdin>", line 1, in <module> which is not helpful (assuming I'm evaluating more complex code, it would be difficult to trace back the line in the editor / file itself).

That's by design because you typed your code into the REPL via stdin, hence that being the fake file name. Otherwise since you are not operating from a file there isn't really a concept of a file to specify.

Similarly, when I evaluate this:

print(os.path.abspath(os.path.curdir))

I get the equivalent of ~/.

When I execute the script from shell, I get the equivalent of pwd

That's all going to depend on how you launched Python (and I advice you use os.getcwd() if you want the current directory and are not going to use pathlib). If you specify the path to a script, then the current working directory is the directory the script is in. If you simply launch the REPL then it's the directory you are in when you launch the REPL.

As far as I understand, this is something that will end up having to be handled in this extension, by letting the interpreter know the location of submitted code, and possibly changing the working directory before submitting the code.

As I said, this isn't under our control and Python does not directly provide a mechanism to fake a file name for the REPL, nor do I even have a good idea of what fake file name to specify since the REPL has no path to speak of.

Note that in jupyter notebooks, it doesn't suffer from the same issue, I assume it does the operations I describe.

I don't know what Jupyter does in this instance, but it would be specific to Jupyter and not Python itself which is what we launch on your behalf when you run Python's REPL.

still have a gut feeling the extension itself will need to be adjusted, more à propos here than on the forum which touches on the language itself.

As I have said, there is nothing here for the extension to adjust as what you are asking for is not how Python's REPL operates. As such, I continue to consider this issue closed and will probably not reply further to this issue.

[smoothdeveloper]

@brettcannon, it is a bit of a shame we can't find a middle ground to discuss the two usability issues I brought, which limit the user friendliness of the REPL integration that this extension provides.

That's by design because you typed your code into the REPL via stdin, hence that being the fake file name. Otherwise since you are not operating from a file there isn't really a concept of a file to specify.

I'm not typing any code in the REPL, I'm selecting it in a file in the vscode text editor, this extension is doing the "typing in" when I use the action to submit the code I selected.

How the F# vscode extension does:

https://github.com/ionide/ionide-vscode-fsharp/blob/11de177d381ab35bc48896649d5eab678bacbcb4/src/Components/Fsi.fs#L336-L355

How the F# REPL does:

https://github.com/dotnet/fsharp/blob/d441308a78724ea47584027af697789c8d2e1a94/src/Compiler/Interactive/fsi.fs#L3761-L3768

Achieving the same usability (focusing on the file name and line number in stack traces for now) in python will require both the interpreter and the extension to collaborate, and if we'd agree it would make the world better, we could break it down into:

• a PEP to make the REPL understand similar directives that the F# REPL understands
• adjusting the python debug info / stack trace printing to keep track of the contextual file name and line number
• having this hooked into the extension the way ionide and the other F# REPL enabled IDEs do
• consider another PEP for introducing symbols equivalent to __SOURCE_DIRECTORY__ and __SOURCE_FILE__ which make it dead easy to refer to a filesystem path next to or relative to a python file, across platforms and environments

Is there any interest to change the status-quo? How can we collaborate to get in that direction?

[brettcannon]

I'm not typing any code in the REPL, I'm selecting it in a file in the vscode text editor, this extension is doing the "typing in" when I use the action to submit the code I selected.

Correct, which makes it the same as if you had copy-and-pasted it in or typed it all out manually. We aren't doing anything special here with the REPL is my point.

Is there any interest to change the status-quo?

Unfortunately I personally don't have the time to push for this sort of change upstream. We are looking into what a VS Code-specific REPL experience may look like, and in that scenario we may control enough to be able to handle mapping tracebacks back to the code that caused it (but no promises).

ow can we collaborate to get in that direction?

You definitely don't need me to propose such a change upstream. You can go to discuss.python.org and there's an Ideas category where you can bring up proposals. See https://peps.python.org/pep-0001/ for what it takes to author a PEP.

[smoothdeveloper]

Thanks for the additional considerations @brettcannon, and it is good to know that the REPL experience is under consideration, in a more general sense, even if my particular issue / suggestion is not something that gets into the scope.

I've submitted the idea, and based on your feedback, I may open an issue specific to the backtraces, just to track it separately.

https://discuss.python.org/t/improve-backtraces-in-repl-context-with-ability-to-interpret-a-line-directive-or-equivalent/39952