Yesterday's response had a list inside. Some tools return information about a single thing — your account profile, a specific message, a single sheet's metadata. Their dicts are flat: keys like email, messages_total, name.
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = result.get("messages", [])
first = messages[0] if messages else {}
print(first.get("id", ""))
Same .get pattern — that's still the right reflex even on the single-message dict?
Yes. Every API response dict deserves the safe-read treatment. The cost is one extra word; the benefit is your script doesn't crash when the API returns something slightly different on an edge case. Make it a habit.
And the inline if messages else {} — Python conditional expression?
Yep — a value that depends on a condition, written as value_if_true if condition else value_if_false. messages[0] if messages else {} reads: "the first message if there is one, otherwise an empty dict". Saves you a 4-line if/else.
When a tool returns information about one thing rather than a list, the response is a flat dict. Read individual fields with .get(key, default):
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = result.get("messages", [])
if messages:
first = messages[0]
print(first.get("id", "")) # message id
print(first.get("snippet", "")) # first ~150 chars of the body
else:
print("inbox empty")Compact alternative to a 4-line if/else when you just want to assign a value:
first = messages[0] if messages else {}
# equivalent to:
if messages:
first = messages[0]
else:
first = {}Use the inline form for short, simple choices. Reach for the multi-line if when the body has multiple statements.
| Tool | Useful keys |
|---|---|
GMAIL_FETCH_MESSAGE_BY_MESSAGE_ID | id, subject, snippet, from, to, body |
GOOGLECALENDAR_FIND_EVENT | id, summary, start, end |
NOTION_RETRIEVE_PAGE | id, properties, created_time |
SLACK_LOOKUP_USER_BY_EMAIL | id, real_name, profile |
Always prefer .get over [] indexing — even when the docs say a key is always present, defensive reading costs nothing and saves you from one class of midnight bug.
Yesterday's response had a list inside. Some tools return information about a single thing — your account profile, a specific message, a single sheet's metadata. Their dicts are flat: keys like email, messages_total, name.
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = result.get("messages", [])
first = messages[0] if messages else {}
print(first.get("id", ""))Same .get pattern — that's still the right reflex even on the single-message dict?
Yes. Every API response dict deserves the safe-read treatment. The cost is one extra word; the benefit is your script doesn't crash when the API returns something slightly different on an edge case. Make it a habit.
And the inline if messages else {} — Python conditional expression?
Yep — a value that depends on a condition, written as value_if_true if condition else value_if_false. messages[0] if messages else {} reads: "the first message if there is one, otherwise an empty dict". Saves you a 4-line if/else.
When a tool returns information about one thing rather than a list, the response is a flat dict. Read individual fields with .get(key, default):
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = result.get("messages", [])
if messages:
first = messages[0]
print(first.get("id", "")) # message id
print(first.get("snippet", "")) # first ~150 chars of the body
else:
print("inbox empty")Compact alternative to a 4-line if/else when you just want to assign a value:
first = messages[0] if messages else {}
# equivalent to:
if messages:
first = messages[0]
else:
first = {}Use the inline form for short, simple choices. Reach for the multi-line if when the body has multiple statements.
| Tool | Useful keys |
|---|---|
GMAIL_FETCH_MESSAGE_BY_MESSAGE_ID | id, subject, snippet, from, to, body |
GOOGLECALENDAR_FIND_EVENT | id, summary, start, end |
NOTION_RETRIEVE_PAGE | id, properties, created_time |
SLACK_LOOKUP_USER_BY_EMAIL | id, real_name, profile |
Always prefer .get over [] indexing — even when the docs say a key is always present, defensive reading costs nothing and saves you from one class of midnight bug.
Create a free account to get started. Paid plans unlock all tracks.