python / python/cpython

pyrepl should provide full traceback if possible to help debug possible buggy failures.

Open
#127,442 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

topic-repl type-feature
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

Bug report

Bug description:

Currently pyrepl has the following bug that is hard to debug:

config.site_import is value: '0'
config.user_site_directory is value: '0'
config.site_import is value: '0'
config.user_site_directory is value: '0'
Python 3.14.0a2+ (heads/main-dirty:49f15d8667e, Nov 29 2024, 21:28:03) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\Users\user\AppData\Roaming\Python\Python314\site-packages\easy-install.pth
warning: can't use pyrepl: 'NoneType' object does not support the context manager protocol (missed __exit__ method)
>>> 

This bug then results in site.py getting imported anyways despite my setting config.site_import AND config.user_site_directory in my own version of Py_Initialize in my C program that embeds the interpreter on Windows (exe). This results in the incorrect appending of the user site-packages folder at the end of sys.path that I did NOT OPT into at all. I did NOT want the interpreter to go about trying to open any pth file for which my own OpenCodeHook successfully captured and printed to my console to let me know that site.py was imported when it should not have been imported at all.

As such if tracebacks were printed whenever it would print the warning that pyrepl cannot be used it would help all possible situations where pyrepl cannot be used and give the user more information into fixing the root problem itself (even if it means pull requesting this repository with a fix for pyrepl itself).

Long story short EXTRA information is better than NOT ENOUGH information to debug and fix problems with pyrepl on embedded interpreters. Likewise site.py and the user site packages folder should be optional and not a hard requirement to using pyrepl either. Basically any and all places in this repository that imports site.py without checking if both config.site_import and config.user_site_directory should be made to check them first before attempting to import it, even if pyrepl cannot be used.

CPython versions tested on:

3.14, CPython main branch

Operating systems tested on:

Windows

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing where pyrepl emits the warning that it cannot be used and where site.py is imported during interpreter initialization. Check how config.site_import and config.user_site_directory are handled, then identify tests covering embedded interpreters or pyrepl failures. Done means the warning includes a full traceback and the reported configuration is respected before site.py is imported.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.