modeling_utils unsafely accesses sys.modules[]

[cjkindel]

System Info

• transformers version: 5.3.0.dev0
• Platform: macOS-26.3.1-arm64-arm-64bit
• Python version: 3.11.12
• Huggingface_hub version: 1.6.0
• Safetensors version: 0.7.0
• Accelerate version: not installed
• Accelerate config: not found
• DeepSpeed version: not installed
• PyTorch version (accelerator?): 2.5.1 (NA)
• Using distributed or parallel set-up in script?: N/A

Who can help?

@Cyrilvallez
@ArthurZucker

Information

• The official example scripts
• My own modified scripts

Tasks

• An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
• My own task or dataset (give details below)

Reproduction

Run this:

import sys
from transformers.models.clip.modeling_clip import CLIPTextModel, CLIPTextConfig

# Simulate condition where module is absent from sys.modules
del sys.modules["transformers.models.clip.modeling_clip"]

config = CLIPTextConfig()
CLIPTextModel(config)  # KeyError before this fix, succeeds after

I submitted a fix PR for this but it was incorrectly closed as AI slop. While I did use Claude to help me debug and isolate the problem, I can assure you this is a real fix submitted by a real human with real customers impacted by this bug.

Expected behavior

Uncaught KeyError exceptions are not raised by module importing logic

[Cyrilvallez]

Please explain why you would delete modules in sys? This is not a bug, this is intentional user breakage 😅

[ArthurZucker]

@Cyrilvallez it sounds weird but some of the vLLM CI is breaking because we deleted transformers.models.clip.clip_image_processor_fast. But we have something like a hack to import ClipImageProcessorFast that return the one from transformers.models.clip.clip_image_processor. But for remote code / when you reload the codebase or you are still trying to access it (remote code that imports in a weird way).

This could help for our remote code compat

[ArthurZucker]

But I think it was fix for clip specifically?

[cjkindel]

Griptape Nodes juggles Library dependencies by directly interacting with sys.modules. I know, it is not advised and we are working away from this pattern. But the root issue remains that sys.modules.get() is much safer than sys.modules[]. I know its a unique bug/use case that is not Pythonic but customers (like myself) do dumb things sometimes.

[Lidang-Jiang]

Hi @ArthurZucker, @Cyrilvallez -- I'd like to submit a fix for this.

The change is minimal: replace sys.modules[cls.__module__] with sys.modules.get(cls.__module__) on lines 1951 and 1970 of modeling_utils.py, and add class_module is None to the existing guard on lines 1953 and 1972. This matches the pattern already used in dynamic_module_utils.py:293. Total diff: 4 lines changed in production code, plus a small regression test.

I checked that there are no open PRs for this (both #44978 and #45015 are closed).

Happy to proceed if a maintainer approves.