You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Compilation on Linux without both libffi-dev and libncurses-dev results in an unexpected warning when using the new REPL #131189
Compilation on Ubuntu 24.04.2 with ./configure --with-pydebug without libffi-dev package installed cause the following unexpected warning while loading the resulting executable as ./python:
warning: can't use pyrepl: No module named 'msvcrt'
After installation of libffi-dev and recompilation the warning was resolved.
from .unix_consoleimportUnixConsoleasConsole, _error
exceptImportError:
from .windows_consoleimportWindowsConsoleasConsole, _error
It's unable to load unix_console because of lack of libffi-dev (and _ctypes) package cause the following import error:
File "/home/dzmitry/cpython/Lib/_pyrepl/readline.py", line 46, in <module>
from .unix_console import UnixConsole as Console, _error
File "/home/dzmitry/cpython/Lib/_pyrepl/unix_console.py", line 35, in <module>
from . import curses
File "/home/dzmitry/cpython/Lib/_pyrepl/curses.py", line 28, in <module>
from . import _minimal_curses as _curses # type: ignore[no-redef]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/dzmitry/cpython/Lib/_pyrepl/_minimal_curses.py", line 12, in <module>
import ctypes
File "/home/dzmitry/cpython/Lib/ctypes/__init__.py", line 8, in <module>
from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
So it fallbacks to import of windows_console on Linux, resulting in another ModuleNotFoundError that results in the No module named 'msvcrt' warning.
In such situation, I'd expect to see a warning about lack of _ctypes. So, may we have here some platform checks instead of catching and suppressing import errors?
cc @encukou WDYT is the best approach? (and how do we actually check it?) I'm actually surprised that make correctly worked here (aren't we checking the necessary dependencies?)
Maybe we should warn once we're done with make? like, if ctypes is not available and we're on Linux, then the new REPL won't work (maybe the old REPL could work?) Having a simple warning: can't use pyrepl: No module named 'msvcrt' doesn't really help in this case.
Compilation on Ubuntu 24.04.2 with ./configure --with-pydebug without libffi-dev package installed cause the following unexpected warning while loading the resulting executable as ./python:
warning: can't use pyrepl: No module named 'msvcrt'
After installation of libffi-dev and recompilation the warning was resolved.
We can't backport this to 3.13, too much of a code difference between the branches and treating this as a bug fix is a stretch (that we used for 3.14, but that's before the final release).
Activity
StanFromIreland commentedon Mar 13, 2025
Yes, its listed as a dependency. Behavior like this is to be expected. I don't really see a need for anything to be introduced (eg warnings).
plashchynski commentedon Mar 13, 2025
After a quick exploration, I've found that the warning caused by an
ImportErrorexception in the following code in pyrepl:cpython/Lib/_pyrepl/readline.py
Lines 45 to 48 in e9d210b
It's unable to load
unix_consolebecause of lack oflibffi-dev(and_ctypes) package cause the following import error:So it fallbacks to import of
windows_consoleon Linux, resulting in anotherModuleNotFoundErrorthat results in theNo module named 'msvcrt'warning.In such situation, I'd expect to see a warning about lack of
_ctypes. So, may we have here some platform checks instead of catching and suppressing import errors?cpython/Lib/_pyrepl/readline.py
Lines 45 to 48 in e9d210b
picnixz commentedon Mar 13, 2025
We should warn at the
makestep or theconfigurestep when libffi is not available I think.picnixz commentedon Mar 13, 2025
cc @encukou WDYT is the best approach? (and how do we actually check it?) I'm actually surprised that
makecorrectly worked here (aren't we checking the necessary dependencies?)encukou commentedon Mar 13, 2025
ctypesis optional;libffiis not a build requirement.I'm not sure anyone knows what “optional” means exactly; see the
zlibdiscussion.picnixz commentedon Mar 13, 2025
Maybe we should warn once we're done with
make? like, ifctypesis not available and we're on Linux, then the new REPL won't work (maybe the old REPL could work?) Having a simplewarning: can't use pyrepl: No module named 'msvcrt'doesn't really help in this case.25 remaining items
pythongh-131189: Fix "msvcrt" import warning on Linux when "_ctypes" …
[3.14] gh-131189: Fix "msvcrt" import warning on Linux when "_ctypes"…
pythongh-131189: Fix "msvcrt" import warning on Linux when "_ctypes" …
jkfields commentedon Aug 4, 2025
I received the same message with Python 3.13.5 on RHEL 9! I had to install ncurses-devel and readline-devel to make it go away.
skirpichev commentedon Aug 5, 2025
#131201 is not backported to 3.13.
If this is intentional, then the bugreport might be closed. @ambv?
pythongh-131189: Fix "msvcrt" import warning on Linux when "_ctypes" …
chris-eibl commentedon Aug 24, 2025
If possible, it would be nice to be backported since this frequently pops up (just recently https://discuss.python.org/t/cant-use-pyrepl-no-module-named-msvcrt-in-linux/67037/9). IDK whether #131201 qualifies for backport, though, but looks quite simple if that helps backporting :)
[3.14] pythongh-131189: Fix "msvcrt" import warning on Linux when "_c…
ambv commentedon Sep 15, 2025
We can't backport this to 3.13, too much of a code difference between the branches and treating this as a bug fix is a stretch (that we used for 3.14, but that's before the final release).
pythongh-131189: Fix "msvcrt" import warning on Linux when "_ctypes" …
[3.13] gh-131189: Fix "msvcrt" import warning on Linux when "_ctypes"…
gh-131189: Remove `curses` mention from `PYTHON_BASIC_REPL` docs (#14…
pythongh-131189: Remove `curses` mention from `PYTHON_BASIC_REPL` docs (
[3.14] gh-131189: Remove `curses` mention from `PYTHON_BASIC_REPL` do…