RFC: Standardizing `pretty_repr` for Complex Content Blocks

[tanujbhaud]

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.