Code in top-level file loses access to variables in Interactive (REPL) session

[palswim]

Bug report

Bug description:

After upgrade from Python 3.12, code in a top-level file can no longer access variables (like modules, etc.) when the execution begins the interactive session.

In the simplest example, suppose I have a file, code.py that contains the following:

import os

Now, if I run Python with this module interactively (python -i code.py), I can't access the os module in the Interactive (REPL) session:

>>> os.listdir('.')
NameError: name 'os' is not defined. Did you forget to import 'os'?

But, to illustrate why this is a problem, consider if code.py had the following contents:

import os
from threading import Thread

def __nstest():
	import time
	time.sleep(5)
	print(os.listdir('.'))

if __name__ == '__main__':
	Thread(target=__nstest).start()
	print(os.listdir('.'))

Again, still a contrived example, but if my __main__ module is passing a function for use later in execution, but that function can no longer access the modules that the __main__ module has imported, this leads to broken execution of code that formerly worked prior to Python 3.13 in Interactive mode. This sounds like it may relate to the new REPL and namespace issues that have arisen (gh-118908).

CPython versions tested on:

3.13.9

Operating systems tested on:

Linux

[ronaldoussoren]

FWIW, I cannot reproduce this with 3.12 and 3.14 on macOS:

% python3.14 -i t.py
>>> os
<module 'os' (frozen)>
>>> 

When I name the file code.py I get an error about Failed calling sys.__interactivehook__ which is expected because code.py shadows the name of a stdlib module that' s used by the new REPL. This results in falling back to the old REPL, and that behaves as expected.

[StanFromIreland]

On Linux with 3.14/main, I also cannot reproduce:

$ cat test.py
import os
$ cpython -i test.py 
>>> os
<module 'os' from '/home/stan/dev/cpython/Lib/os.py'>
>>> 

[gvanrossum]

Can't repro in main (3.15.a2+) using either new REPL or basic (old) REPL.

But I can confirm that if you are on VS Code and make the mistake of Ctrl-clicking on the "Ctrl click to launch VS Code Native REPL" line, you indeed do not see the contents of the file passed. Maybe this is what happened?

@palswim Can you explain how you are running Python3.14?

[palswim]

My apologies, I was using Python 3.13.9, but just from the command line. A more complete terminal session:

$ cat test.py 
import os
$ python3 --version
Python 3.13.9
$ python3 -i test.py 
>>> os
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    os
NameError: name 'os' is not defined. Did you forget to import 'os'?

And also, a session with the Threading code I supplied:

$ cat nstest.py 
import os
from threading import Thread

def __nstest():
        import time
        time.sleep(5)
        print(os.listdir('.'))

if __name__ == '__main__':
        Thread(target=__nstest).start()
        print(os.listdir('.'))
$ python3 -i nstest.py 
['test.py', 'nstest.py']
>>> 
Exception in Thread-1 (__nstest):
Traceback (most recent call last):
  File "/usr/lib64/python3.13/threading.py", line 1043, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "/usr/lib64/python3.13/threading.py", line 994, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/mnt/home-tmp/1000/Downloads/simple/nstest.py", line 7, in __nstest
    print(os.listdir('.'))
          ^^
NameError: name 'os' is not defined. Did you forget to import 'os'?

>>> 
KeyboardInterrupt
>>> 

[palswim]

Interestingly, if test.py imports a different module, I don't see this behavior:

$ cat test.py 
import email
$ python3 -i test.py 
>>> email
<module 'email' from '/usr/lib64/python3.13/email/__init__.py'>

So, it appears that some behavior is stripping the os module before transferring control to the REPL. And the previous ("basic") REPL does not have this problem:

$ PYTHON_BASIC_REPL=1 python3 -i test.py 
>>> os
<module 'os' (frozen)>

[gvanrossum]

@palswim Thanks! We now have quite a bit more data: it only breaks with the new REPL, and it only breaks for os!

I also checked if I could repro with a file named test.py containing import os but I couldn't.

So none of us can repro this... You have to do more digging on your end. The source code of the new REPL is in Lib/_pyrepl/.

One more question -- do you recall where you got that python3.13 binary? Did it come with your OS? (What OS distribution and version?)

[tanloong]

@palswim Could a del os command in your PYTHONSTARTUP config be causing this?

C:main$ $env:PYTHONSTARTUP = "startup.py"
C:main$ cat startup.py
del os
C:main$ cat test.py
import os
C:main$ python3.13 -i test.py
>>> os
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    os
NameError: name 'os' is not defined. Did you forget to import 'os'?
>>> ^Z
C:main$ $env:PYTHON_BASIC_REPL=1
C:main$ python3.13 -i test.py
>>> os
<module 'os' (frozen)>

[palswim]

@tanloong Indeed it does; the distribution's PYTHONSTARTUP file in an attempt to reduce overhead deletes all namespaces that it imported:

# cleanup
del os, atexit, readline, rlcompleter, save_history, historyPath

This file hasn't changed in 5+ years, but, with the differences in how the new and old REPL work, this issue is manifesting now. I am sure that we could change the new REPL to accommodate this behavior, but it sounds like troubleshooting should happen now with the distribution, instead. Thank you all for your time in investigating this.

[gvanrossum]

Thank you.