gh-119102: Fix REPL for dumb terminal

[vstinner]

Move CAN_USE_PYREPL variable from _pyrepl.main to _pyrepl and rename it to _CAN_USE_PYREPL. Use the variable in the site module to decide if _pyrepl.write_history_file() can be used.

• Issue: New pyrepl gives a traceback on exit with "dumb" terminal #119102

[vstinner]

cc @pablogamboa@ambv

[eugenetriguba]

question: This is working, I presume, because we're hitting the except block in __main__ when we have a dumb TERM setting? I was initially a bit confused because I wasn't seeing why an extra conditional on a setting for a win32 check would fix this

[vstinner]

_pyrepl._CAN_USE_PYREPL is set to False if pyrepl fails at startup.

[vstinner]

@ambv: Do you have an idea on how to fix mypy?

[eugenetriguba]

@vstinnerUsing from . import _CAN_USE_PYREPL instead of import _pyrepl seems to work. Not sure if there is a better solution It seems to work in that it makes mypy happy, but it wouldn't allow updating the variable in the other module 🙂

[vstinner]

@vstinner Using from . import _CAN_USE_PYREPL instead of import _pyrepl seems to work.

In that case, _CAN_USE_PYREPL = False only sets the variable in __main__.py, not in __init__.py.

[vstinner]

I rewrote the fix to please the typing gods.

[miss-islington-app]

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-119308 is a backport of this pull request to the 3.13 branch.

[danielhollas]

I rewrote the fix to please the typing gods.

@vstinner the new version doesn't seem to fix the issue for me (tested on Fedora 39).

I've ran into the same problem when I was trying to fix this. It looks like from _pyrepl.__main__ import CAN_USE_PYREPL re-executes the code in __main__, and therefore CAN_USE_PYREPL will always be True on non-windows systems.

[lysnikolaou]

Same behavior for me that @danielhollas described.

[vstinner]

Sorry, I didn't retest functionally after fixing mypy 😬

[vstinner]

Please check my second fix: PR gh-119332.