Executing `from . import *` within the REPL will import the `_pyrepl` package, But executing with the `-c` argument will result in an error.

[KrisTHL181]

Bug report

Bug description:

My working directory is under MyProject, which includes an __init__.py file and other necessary files to be recognized as a package.
But when I try to run the code from . import * in the shell using Python, there are two different outcomes in the two invocation methods (argument passing and REPL execution).
The folder looks like:
├── main.py
├── init.py
├── _implements.py
└── code.py

(PythonProject) C:\Users\KrisT\Desktop\PythonProject>python -c "from . import *"
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 from . import *
ImportError: attempted relative import with no known parent package

(PythonProject) C:\Users\KrisT\Desktop\PythonProject>python -q
>>> import sys;print(sys.version_info)
sys.version_info(major=3, minor=13, micro=1, releaselevel='final', serial=0)
>>> from . import *
>>> dir()
['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'commands', 'completing_reader', 'console', 'historical_reader', 'input', 'keymap', 'main', 'reader', 'readline', 'simple_interact', 'sys', 'trace', 'types', 'utils', 'windows_console']
>>> print(console)
<module '_pyrepl.console' from 'E:\\Python\\Lib\\_pyrepl\\console.py'>
>>> print(input)
<module '_pyrepl.input' from 'E:\\Python\\Lib\\_pyrepl\\input.py'>
>>> print(keymap)
<module '_pyrepl.keymap' from 'E:\\Python\\Lib\\_pyrepl\\keymap.py'>
>>>

It loaded the _pyrepl package instead of my PythonProject.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

Linked PRs

• gh-127960 Fix the REPL to set the correct namespace by setting the correct __main__ module #134275
• [3.14] gh-127960 Fix the REPL to set the correct namespace by setting the correct __main__ module (gh-134275) #134473

[picnixz]

Did it work on 3.12? cc @pablogsal

[KrisTHL181]

No. It only appears in the new REPL. (I used Anaconda to create a 3.12 environment for testing.)

(base) C:\Users\KrisT\Desktop>E:\Anaconda\python.exe -q
>>> import sys;print(sys.version_info)
sys.version_info(major=3, minor=12, micro=3, releaselevel='final', serial=0)
>>> from . import *
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: attempted relative import with no known parent package
>>> exit()
(base) C:\Users\KrisT\Desktop>E:\Anaconda\python.exe -c "from . import *"
Traceback (most recent call last):
 File "<string>", line 1, in <module>
ImportError: attempted relative import with no known parent package

[whitphx]

Hi let me take a look into it (from PyConUS sprint).
I could reproduce it on mac with Python 3.15 as well

Python 3.15.0a0 (heads/main:faebf87b37, May 19 2025, 11:40:30) [Clang 17.0.0 (clang-1700.0.13.3)] on darwin

[ambv]

As you witnessed with the old REPL, using relative imports within the REPL is not something that's supposed to work. The PR that intends to restore the pre-PyREPL behavior here is a good idea.

[whitphx]

@ambv Thank you! Let me ask you and @pablogsal questions:

Looks like PyREPL is intentionally designed to execute the REPL in a namespace derived from the _pyrepl module and it's ensured by the tests such as a checker method and this test case. This comment implies it as well, and the autocompletion also assumes this behavior as @tomasr8 commented.

Another related concern is the behavior of PyREPL and its autocompletion with the -m option.
If you launch the PyREPL by python -i -m spam_project, the REPL is in the namespace of spam_project, not _pyrepl. It may look inconsistent, and the autocompletion still suggests the modules in _pyrepl which is no longer valid.

I originally tried to make the PyREPL behave like the old REPL in #134275 as you wrote, but I found it would affect such a wide range of code, so I would like to ask what's a good direction before digging it deeper.

I think there are options like this. Which do you think is good?

1. Admit this relative import behavior is a natural consequence of the namespace design and close this issue without fix. (Zero fix)
2. Workaround the relative import behavior only, while keeping the namespace design itself. This fix might be something like just adding namespace["__package__"] = None to here.
3. Modify the PyREPL not to run inside the _pyrepl namespace like gh-127960 Fix the REPL to set the correct namespace by setting the correct __main__ module #134275 , while it affects more lines of code.

@pablogsal advised me to keep the change small to tackle this issue which I totally agree with.
But now I also concern that the change can be larger anyway If we want to take care of the auto-completion and the case of -m as well.

[ambv]

@whitphx early in the day I made some changes/additions to your PR to make the tests no longer expect the _pyrepl package. This is a good direction. Now we need to fix the auto-completion and -i. The changes might not be trivial, but I still expect the PR to be relatively small. I'm not concerned about the size here.

We will only be doing this for Python 3.14+.

[whitphx]

Thank you @ambv . I will work on the PR to enhance it more.

(I already left PyConUS sprints but will make time to do it definitely)