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: gh-119102

[vstinner]

cc @pablogamboa @ambv

[vstinner]

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

[eugenetriguba]

@vstinner ~Using 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[bot]]

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

[bedevere-app[bot]]

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.