GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — shadowing error with `traceback` module leads to unexpected code execution · Issue #138170 · python/cpython

shadowing error with traceback module leads to unexpected code execution #138170

New issue
Copy link
New issue
Copy link
Closed as duplicate
Closed as duplicate
shadowing error with traceback module leads to unexpected code execution#138170
Copy link
Labels
invalid

Description

@tideofwords
tideofwords
opened on Aug 26, 2025
Issue body actions

Bug report

Bug description:

Python's traceback module is not a built-in module. This means that the user can shadow it by putting their own traceback.py file in the module search path. When an exception is raised, the exception-handling mechanism will try to import the traceback module, resulting in the unexpected execution of user-defined code.


Here is a minimal example in Python 3.13.5 with the CPython interpreter. I create two files, each with one line of code, and put them in the same directory:

a.py # this will raise an exception

print(x)

traceback.py # this will be called unexpectedly

print("THIS CODE SHOULD NOT RUN")

When I run a.py, the code in traceback.py also runs.

% python a.py
Traceback (most recent call last):
THIS CODE SHOULD NOT RUN
Traceback (most recent call last):
  File "/Users/brian/Documents/prog/bug/a.py", line 1, in <module>
    print(x)
NameError: name 'x' is not defined

I'm aware that module import shadowing is a known feature of the language. Usually, this issue only arises when the developer has either invoked import or redefined a built-in object -- so that there is some indication of the cause of the issue in the code itself. This case is unique in that the troublesome import occurs in the CPython implementation itself, and there is no sign in the Python code that a shadowing error might occur.

Note that built-in modules receive special treatment to prevent precisely this.
https://docs.python.org/3/tutorial/modules.html#the-module-search-path
The Python interpreter searches for built-in modules before searching sys.path. If traceback were a built-in module, this would not happen.


You can also get this behavior by shadowing other modules which are imported from traceback, such as ast. So if you rename traceback.py to ast.py in the example above, the same thing happens.

It seems that this is because when modules are imported in order to print a traceback, they are imported in sys.path order without checking builtins first.


The strange behavior first appeared after PR 110721 was approved.
#110702

CPython versions tested on:

3.13

Operating systems tested on:

Linux, macOS

Linked PRs

  • gh-138170: traceback file maybe use local import for trace print #138179

Activity

  1. tideofwords
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    on Aug 26, 2025
  2. yihong0618 commented on Aug 27, 2025

    @yihong0618
    yihong0618
    on Aug 27, 2025
    Contributor
    More actions

    This exists on python3.13 - main

    ➜  py314 uv run python --version 
    Python 3.14.0rc2
    ➜  py314 cat traceback.py 
    import os
    print("THIS CODE SHOULD NOT RUN")
    print(os.listdir())
    print("111111111111111111111111")
    ➜  py314 uv run a.py
    THIS CODE SHOULD NOT RUN
    ['a.py', 'traceback.py', '__pycache__', '.python-version']
    111111111111111111111111
    Traceback (most recent call last):
      File "/Users/hyi/py314/a.py", line 1, in <module>
        print(x)
    NameError: name 'x' is not defined
    
  3. StanFromIreland
    added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    on Aug 27, 2025
  4. picnixz commented on Aug 28, 2025

    @picnixz
    picnixz
    on Aug 28, 2025
    Member
    More actions

    Shadowing a module in Lib is not recommended, and we can't really do anything about it. This is a duplicate of #101210 for instance.

  5. picnixz commented on Aug 28, 2025

    @picnixz
    picnixz
    on Aug 28, 2025
    Member
    More actions

    The workaround is to use name different from an stdlib module. It's not possible to distinguish between which module the user would want to import and whether it's a legitimate shadowing or not (this is the way imports behave).

  6. picnixz
    closed this as a duplicateof Stdlib packages import local packages from working dir instead of other stdlib packages #101210 on Aug 28, 2025
  7. picnixz
    added
    invalid
    and removed
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    on Aug 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    invalid

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.