Skip to content

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

Closed
Closed
Executing from . import * within the REPL will import the _pyrepl package, But executing with the -c argument will result in an error.#127960
Labels
stdlibStandard Library Python modules in the Lib/ directorytopic-replRelated to the interactive shelltype-bugAn unexpected behavior, bug, or error

Description

@KrisTHL181
KrisTHL181
opened on Dec 15, 2024

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

Activity

  1. KrisTHL181
    added
    type-bugAn unexpected behavior, bug, or error
    on Dec 15, 2024
  2. picnixz
    added
    topic-replRelated to the interactive shell
    on Dec 15, 2024

  3. picnixz commented on Dec 15, 2024

    @picnixz
    picnixz
    on Dec 15, 2024
    Member

    Did it work on 3.12? cc @pablogsal

  4. picnixz
    added
    stdlibStandard Library Python modules in the Lib/ directory
    on Dec 15, 2024

  5. KrisTHL181 commented on Dec 15, 2024

    @KrisTHL181
    KrisTHL181
    on Dec 15, 2024
    Author

    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

  6. whitphx commented on May 19, 2025

    @whitphx
    whitphx
    on May 19, 2025
    Contributor

    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

  7. ambv commented on May 21, 2025

    @ambv
    ambv
    on May 21, 2025
    Contributor

    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.

  8. whitphx commented on May 21, 2025

    @whitphx
    whitphx
    on May 21, 2025
    Contributor

    @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.

  9. ambv commented on May 21, 2025

    @ambv
    ambv
    on May 21, 2025
    Contributor

    @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+.

  10. whitphx commented on May 21, 2025

    @whitphx
    whitphx
    on May 21, 2025
    Contributor

    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)

  11. ambv
    added a commit that references this issue on May 22, 2025

    gh-127960 Fix the REPL to set the correct namespace by setting the co…

    b1b8962
  12. miss-islington
    added a commit that references this issue on May 22, 2025

    pythongh-127960 Fix the REPL to set the correct namespace by setting …

    250897e
  13. ambv
    added a commit that references this issue on May 22, 2025

    [3.14] gh-127960 Fix the REPL to set the correct namespace by setting…

    9989915
  14. ambv
    closed this as completedon May 25, 2025
  15. lkollar
    added a commit that references this issue on May 26, 2025

    pythongh-127960 Fix the REPL to set the correct namespace by setting …

    dfc5499
  16. Pranjal095
    added a commit that references this issue on Jul 12, 2025

    pythongh-127960 Fix the REPL to set the correct namespace by setting …

    fdc8e08
  17. taegyunkim
    added a commit that references this issue on Aug 4, 2025

    pythongh-127960 Fix the REPL to set the correct namespace by setting …

    248e036
  18. gostak-dd
    added a commit that references this issue on Jun 2, 2026

    pythongh-127960 Fix the REPL to set the correct namespace by setting …

    9fd2fc9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-replRelated to the interactive shelltype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions