An LLM only ever returns text. Build the real parsing logic that turns that raw string into structured data your code can actually use.
1Text In, Text Out — Always
No matter what you ask an LLM for — a list, a number, JSON, a boolean — the API response is fundamentally a string. Anything more structured than that is a convention you (or a parser) impose on top of the raw text, not something the model literally returns as a native data type.
2Why Parsers Must Tolerate Messiness
The exercise's input deliberately had inconsistent spacing around commas — exactly the kind of minor variation real LLM output produces from one generation to the next. A parser that assumes perfectly clean formatting will intermittently fail in production the moment generation drifts even slightly; stripping and filtering defensively is what makes parsing actually reliable.
3Step-by-Step Breakdown
An LLM only ever returns text — even when you ask for a list, a number, or JSON. If your code needs a real Python list to loop over, you need something that reliably converts that raw string into structured data. That's an Output Parser.
LangChain's real CommaSeparatedListOutputParser does exactly this: split on commas, strip stray whitespace, drop anything empty. Small, boring, and exactly the kind of glue code you don't want to rewrite (and get subtly wrong) in every project that needs it.
Build an Output Parser Yourself. Finish parse(): split the raw text on commas, strip whitespace from each piece, and drop anything that's empty after stripping. Notice the messy input on purpose — real LLM output is never as clean as your test cases hope.
Why does a real output parser need to handle inconsistent whitespace and formatting in the raw LLM text, rather than assuming clean, predictable output?
- →LLM text generation is inherently variable — the exact spacing and formatting of a list-like response isn't guaranteed to be identical every time, so a robust parser has to normalize it rather than assume a fixed shape.
- →Because LLM APIs always return text in an inconsistent character encoding.
Module 1 complete: you've built the real fixes for fragile prompts and unstructured output. Module 2 combines both into an actual Chain — the abstraction that sequences a prompt, a model call, and a parser into one reusable unit.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Log Parser Failures With the Raw Input That Caused Them
When a parser fails to extract expected structure from LLM output, log the raw text alongside the failure so developers debugging via logs or assistive tooling can see exactly what was actually returned.
logger.warn(f'Parse failed for: {raw_text!r}')SEO Implications
- 1
Target 'LangChain output parser' and 'parse LLM response to list' as distinct searches
Developers hit this as a specific, practical problem once their prompt asks for structured output and needs to consume it in code.
Best Practices
Always Strip and Filter Parsed LLM Output, Never Assume Clean Formatting
LLM text generation has inherent minor variability — a parser that assumes exact, consistent spacing or formatting will fail intermittently; always normalize (strip whitespace, drop empty results) defensively.
Frequent Bugs
A list parser that splits on commas but doesn't strip whitespace, producing items like ' green ' with leading/trailing spaces that break exact-match comparisons elsewhere in the code.
Always .strip() each parsed item — comparing an un-stripped ' green ' against 'green' elsewhere in your code will silently fail to match.
Real-World Examples
Category Tagging Pipeline
An LLM asked to return comma-separated category tags occasionally adds extra spacing or a trailing comma; a robust parser (like the one you just built) handles both cases identically, while a naive .split(',') alone would leave whitespace and empty-string artifacts in the results.
tags = parser.parse(llm_response) # always clean, always a real list