Issue Station
Sign In
Tools hereToolbox

langchain - 💡(How to fix) Fix RFC: Standardizing `pretty_repr` for Complex Content Blocks [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langchain-ai/langchain#35261•Fetched 2026-04-08 00:26:52
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
tanujbhaudtanujbhaud
Participants
Saad-MallebhariSaad-Mallebharitanujbhaudtanujbhaud
Timeline (top)
commented ×1labeled ×1mentioned ×1subscribed ×1

Root Cause

Readable logs are critical for debugging chains. As LangChain supports more multimodal and agentic workflows, the default repr must evolve to be concise yet informative.

We are happy to implement this pending consensus on the format.

Fix Action

Fix / Workaround

Implementation Strategy

Instead of hardcoding types in BaseMessage, we suggest:

  1. A _get_pretty_repr(block) helper that dispatches based on type.
  2. Allowing BaseMessage subclasses to override this if needed.

Code Example

{'type': 'image_url', 'image_url': {'url': 'https://very-long-url...'}}

---

[image_url]
# OR
[image: https://very-lon...]

---

{'type': 'tool_use', 'name': 'calculator', 'args': {'query': '2+2'}}

---

[tool_use: calculator]
RAW_BUFFERClick to expand / collapse

RFC: Standardizing pretty_repr for Complex Content Blocks

Status: Proposal related-prs: #35248, #35247

Motivation

The current implementation of BaseMessage.pretty_repr() relies on pprint for list-based content. This works well for simple text but becomes unreadable for complex content types common in modern LLM applications, such as:

  • Multimodal inputs: Base64 strings or long image URLs cluttered the logs.
  • Tool Use: JSON arguments are hard to parse visually.

The goal of this RFC is to agree on a standardized, human-readable format for these blocks before implementation, as requested by maintainers.

Proposed Design

We propose introducing a "Block Representation Protocol" where each content block type has a canonical short representation.

1. Image URLs

Current Behavior:

{'type': 'image_url', 'image_url': {'url': 'https://very-long-url...'}}

Proposed Behavior:

[image_url]
# OR
[image: https://very-lon...]

Design Question: Do we prefer total hiding or truncation?

2. Tool Use

Current Behavior:

{'type': 'tool_use', 'name': 'calculator', 'args': {'query': '2+2'}}

Proposed Behavior:

[tool_use: calculator]

Implementation Strategy

Instead of hardcoding types in BaseMessage, we suggest:

  1. A _get_pretty_repr(block) helper that dispatches based on type.
  2. Allowing BaseMessage subclasses to override this if needed.

Why this matters

Readable logs are critical for debugging chains. As LangChain supports more multimodal and agentic workflows, the default repr must evolve to be concise yet informative.

We are happy to implement this pending consensus on the format.

extent analysis

Standardizing pretty_repr for Complex Content Blocks

Fix Plan

1. Introduce a Block Representation Protocol

Create a new module block_repr.py with a dictionary mapping content block types to their canonical short representations.

# block_repr.py
BLOCK_REPR_PROTOCOL = {
    'image_url': '[image_url]',
    'image_url_truncated': '[image: ...]',
    'tool_use': '[tool_use: {}]',
}

2. Implement _get_pretty_repr(block) Helper

In base_message.py, add a _get_pretty_repr(block) helper that dispatches based on the type of the block.

# base_message.py
from block_repr import BLOCK_REPR_PROTOCOL

def _get_pretty_repr(block):
    block_type = block['type']
    if block_type in BLOCK_REPR_PROTOCOL:
        return BLOCK_REPR_PROTOCOL[block_type].format(**block)
    else:
        return repr(block)

3. Override _get_pretty_repr(block) in Subclasses

Allow BaseMessage subclasses to override the _get_pretty_repr(block) method if needed.

# my_message.py (subclass of BaseMessage)
class MyMessage(BaseMessage):
    def _get_pretty_repr(self, block):
        # custom implementation
        pass

Verification

  1. Test the new pretty_repr behavior for different content block types.
  2. Verify that the logs are readable and concise.

Extra Tips

  • Consider adding a max_length parameter to the BLOCK_REPR_PROTOCOL to handle long image URLs.
  • Use a consistent naming convention for the block representation protocol.
  • Document the implementation strategy and the Block Representation Protocol in the code and documentation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#model loading#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING