Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-127960 Fix the REPL to set the correct namespace by setting the correct__main__ module#134275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
The `__main__` module imported in the `_pyrepl` module points to the `_pyrepl` module itself when the interpreter was launched without `-m` option and didn't execute a module,while it's an unexpected behavior that `__main__` can be `_pyrepl` and relative imports such as `from . import *` works based on the `_pyrepl` module.
… REPL.The Python-based REPL (_pyrepl.main.interactive_console) no longer loads the real __main__ module so it should be passed from its caller.
python-cla-botbot commentedMay 19, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
All commit authors signed the Contributor License Agreement. |
Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
The current code degrades#121054 . Will fix it. |
Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
1 similar comment
Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
…) instead of pymain_run_module(L"_pyrepl", 0)This change is an equivalent to the one done inhttps://github.com/python/cpython/pull/120904/files#diff-79e40dbd94b164b5f42a960224cc7496e33c189b4c66a6810904eda7d703b6f2R600Two callers of `pymain_start_pyrepl` differs in whether the PYTHONSTARTUP script is already executed or not, so pythonstartup argument is added to `pymain_start_pyrepl` to control whether it should be executed in it or not.
Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Just wanted to mention that the import autocomplete feature currently assumes that the namespace is Here's the code that does that: cpython/Lib/_pyrepl/_module_completer.py Lines 20 to 21 ine1f8914
|
@tomasr8 good catch, how would you change this PR to make it work then? What test are we missing that should be failing now? |
tomasr8 commentedMay 21, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I shouldn't be surprised, for the purposes of import completion we hardcode so any change to pyrepl itself would not affect it (and neither the tests) I think we can simply set |
Something like this would be a minimal change to align the completer behaviour but we might be able to remove the entire namespace handling inside diff --git a/Lib/_pyrepl/_module_completer.py b/Lib/_pyrepl/_module_completer.pyindex 9aafb55090e..effba0ba23f 100644--- a/Lib/_pyrepl/_module_completer.py+++ b/Lib/_pyrepl/_module_completer.py@@ -17,8 +17,8 @@ def make_default_module_completer() -> ModuleCompleter:- # Inside pyrepl, __package__ is set to '_pyrepl'- return ModuleCompleter(namespace={'__package__': '_pyrepl'})+ # Inside pyrepl, __package__ is set to None+ return ModuleCompleter(namespace={'__package__': None}) |
The added test cases assert* __package__ is None when PyREPL is launched without options* PYTHONSTARTUP works as expected in all the cases; the PyREPL is launched with -m, without -m, and with a file path
Thank you@tomasr8 for the pointer and the snippet. I will take a look into it as well. |
What about changes like this? diff --git a/Lib/_pyrepl/readline.py b/Lib/_pyrepl/readline.pyindex 560a9db192..572eee520e 100644--- a/Lib/_pyrepl/readline.py+++ b/Lib/_pyrepl/readline.py@@ -606,6 +606,7 @@ def _setup(namespace: Mapping[str, Any]) -> None: # set up namespace in rlcompleter, which requires it to be a bona fide dict if not isinstance(namespace, dict): namespace = dict(namespace)+ _wrapper.config.module_completer = ModuleCompleter(namespace) _wrapper.config.readline_completer = RLCompleter(namespace).complete # this is not really what readline.c does. Better than nothing I guess |
@whitphx, yes, this is OK and in fact how the old REPL used to behave: ❯ $PYTHON_BASIC_REPL=1 $PYTHONSTARTUP="" ./python.exe -i -m sysconfigPlatform: "macosx-15.5-arm64"Python version: "3.15"...>>>from .import __main__as m>>> m<module 'sysconfig.__main__' from '/Volumes/RAMDisk/cpython-main/Lib/sysconfig/__main__.py'> And this is PyREPL with the current PR applied, which is the same (correct) behavior: ❯ $PYTHONSTARTUP="" ./python.exe -i -m sysconfigPlatform: "macosx-15.5-arm64"Python version: "3.15"...>>>__file__'/Volumes/RAMDisk/cpython-main/Lib/sysconfig/__main__.py'>>>from .import __main__as m>>> m<module 'sysconfig.__main__' from '/Volumes/RAMDisk/cpython-main/Lib/sysconfig/__main__.py'> |
b1b8962 intopython:mainUh oh!
There was an error while loading.Please reload this page.
…the correct `__main__` module (pythongh-134275)The `__main__` module imported in the `_pyrepl` module points to the `_pyrepl` module itself when the interpreter was launched without `-m` option and didn't execute a module,while it's an unexpected behavior that `__main__` can be `_pyrepl` and relative imports such as `from . import *` works based on the `_pyrepl` module.(cherry picked from commitb1b8962)Co-authored-by: Yuichiro Tachibana (Tsuchiya) <t.yic.yt@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
GH-134473 is a backport of this pull request to the3.14 branch. |
… the correct `__main__` module (gh-134275) (gh-134473)The `__main__` module imported in the `_pyrepl` module points to the `_pyrepl` module itself when the interpreter was launched without `-m` option and didn't execute a module,while it's an unexpected behavior that `__main__` can be `_pyrepl` and relative imports such as `from . import *` works based on the `_pyrepl` module.(cherry picked from commitb1b8962)Co-authored-by: Yuichiro Tachibana (Tsuchiya) <t.yic.yt@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Uh oh!
There was an error while loading.Please reload this page.
from . import *within the REPL will import the_pyreplpackage, But executing with the-cargument will result in an error. #127960