Yesterday's merged list was clean, but nobody could tell which line came from Gmail and which came from Calendar. Today you tag each line at extraction time. How would you prefix every snippet with MAIL: and every event with MEET:?
An f-string inside the comprehension? So each item becomes f"MAIL: {m.get('snippet', '')}" instead of just the raw snippet string?
Exactly. The expression before for can be any Python expression — including an f-string. One line per source:
mails = [f"MAIL: {m.get('snippet', '')}" for m in emails.get("messages", [])]
meets = [f"MEET: {e.get('summary', '')}" for e in events.get("items", [])]And + still glues the two lists? The tag stays attached to each string even after concatenation?
The prefix is baked into each string before the merge, so nothing gets lost. The caller scans a single list and knows source-at-a-glance:
def format_dual_preview(max_emails: int, max_events: int) -> list:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_emails})
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
mails = [f"MAIL: {m.get('snippet', '')}" for m in emails.get("messages", [])]
meets = [f"MEET: {e.get('summary', '')}" for e in events.get("items", [])]
return mails + meetsThe prefix adds five characters per line — does that matter on big inboxes, or is it fine for any size?
Fine for any realistic size. The memory overhead is linear in the number of items, and the readability win dwarfs the few extra bytes. Optimizing here would be premature.
So a tiny prefix transforms a messy merge into a scan-ready feed — that feels like a formatting superpower?
A string template plus a comprehension is how most automations shape data for humans. You'll reach for this pattern whenever the output is read, not just consumed.
TL;DR: Put the label inside the f-string so every line carries its source.
f"MAIL: {m.get('snippet', '')}"MAIL: for Gmail, MEET: for Calendarmails + meets returns a labelled flat list| Strategy | Problem |
|---|---|
| Tag post-merge | Can't tell which item came from where |
| Two parallel lists | Caller juggles two return values |
| Tag inline | Each string self-describes |
Inline tagging is the cheapest refactor-proof shape — add a new source, its prefix, and no other line needs to change.
Yesterday's merged list was clean, but nobody could tell which line came from Gmail and which came from Calendar. Today you tag each line at extraction time. How would you prefix every snippet with MAIL: and every event with MEET:?
An f-string inside the comprehension? So each item becomes f"MAIL: {m.get('snippet', '')}" instead of just the raw snippet string?
Exactly. The expression before for can be any Python expression — including an f-string. One line per source:
mails = [f"MAIL: {m.get('snippet', '')}" for m in emails.get("messages", [])]
meets = [f"MEET: {e.get('summary', '')}" for e in events.get("items", [])]And + still glues the two lists? The tag stays attached to each string even after concatenation?
The prefix is baked into each string before the merge, so nothing gets lost. The caller scans a single list and knows source-at-a-glance:
def format_dual_preview(max_emails: int, max_events: int) -> list:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_emails})
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
mails = [f"MAIL: {m.get('snippet', '')}" for m in emails.get("messages", [])]
meets = [f"MEET: {e.get('summary', '')}" for e in events.get("items", [])]
return mails + meetsThe prefix adds five characters per line — does that matter on big inboxes, or is it fine for any size?
Fine for any realistic size. The memory overhead is linear in the number of items, and the readability win dwarfs the few extra bytes. Optimizing here would be premature.
So a tiny prefix transforms a messy merge into a scan-ready feed — that feels like a formatting superpower?
A string template plus a comprehension is how most automations shape data for humans. You'll reach for this pattern whenever the output is read, not just consumed.
TL;DR: Put the label inside the f-string so every line carries its source.
f"MAIL: {m.get('snippet', '')}"MAIL: for Gmail, MEET: for Calendarmails + meets returns a labelled flat list| Strategy | Problem |
|---|---|
| Tag post-merge | Can't tell which item came from where |
| Two parallel lists | Caller juggles two return values |
| Tag inline | Each string self-describes |
Inline tagging is the cheapest refactor-proof shape — add a new source, its prefix, and no other line needs to change.
Create a free account to get started. Paid plans unlock all tracks.