Skip to content

New REPL does not include globals from executed module when used with -i #120678

Description

@AlexWaygood

Bug report

Bug description:

If I have a module called foo.py with the following contents in the root of my CPython local clone:

class Foo: pass

Then running PYTHON_BASIC_REPL=1 ./python.exe -i foo.py, I get the following behaviour: foo.py is executed, and the Foo class is available in the globals of the REPL:

~/dev/cpython (main)⚡ % PYTHON_BASIC_REPL=1 ./python.exe -i foo.py 
>>> Foo
<class '__main__.Foo'>

But with the new REPL, the Foo class isn't available!

~/dev/cpython (main)⚡ % ./python.exe -i foo.py 
>>> Foo
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    Foo
NameError: name 'Foo' is not defined
>>> 

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    3.13only security fixes
    3.14bugs and security fixes
    topic-replRelated to the interactive shell
    on Jun 18, 2024
  2. eryksun commented on Jun 18, 2024

    @eryksun
    Contributor

    It seems the new REPL doesn't get executed in the __main__ namespace. This can be worked around manually:

    $ python -ic "class Foo: pass"
    
    >>> Foo
    Traceback (most recent call last):
      File "<python-input-0>", line 1, in <module>
        Foo
    NameError: name 'Foo' is not defined
    >>> import sys
    >>> from _pyrepl.simple_interact import run_multiline_interactive_console
    >>> run_multiline_interactive_console(sys.modules['__main__'])
    >>> Foo
    <class '__main__.Foo'>
    >>> dir()
    ['CAN_USE_PYREPL', 'Foo', '__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'interactive_console', 'os', 'sys']

    This can be addressed in "Lib/_pyrepl/__main__.py". All imports and assignments in that module (e.g. CAN_USE_PYREPL, interactive_console, os, and sys) should be uniquely prefixed to avoid collisions and to allow clearing them before calling run_interactive(mainmodule).

  3. vstinner commented on Jun 20, 2024

    @vstinner
    Member

    I marked #120798 as a duplicate of this issue.

  4. AlexWaygood commented on Jun 22, 2024

    @AlexWaygood
    MemberAuthor

    This is a regression that was caused by #119547.

  5. self-assigned this
    on Jun 22, 2024
  6. added 2 commits that reference this issue on Jun 22, 2024
  7. added a commit that references this issue on Jul 17, 2024
  8. added a commit that references this issue on Jul 17, 2024
  9. added 2 commits that reference this issue on Jul 17, 2024
  10. added a commit that references this issue on Jul 17, 2024
  11. added a commit that references this issue on Jul 17, 2024
  12. added a commit that references this issue on Jul 17, 2024
  13. ambv commented on Jul 22, 2024

    @ambv
    Contributor

    This is solved now, thanks everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.13only security fixes3.14bugs and security fixestopic-replRelated to the interactive shelltype-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions