Pythonic Code in 2026 Is Explicit at the Boundaries

The clever version passed review because it was short.

active_names = list(map(lambda u: u.name, filter(lambda u: u.active, users)))

Then the requirement changed. Suspended users had to be excluded. Test users had to be included only in staging. The one-liner turned into a small riddle, and the next engineer rewrote it as the code it should have been from the beginning.

active_names = [
    user.name
    for user in users
    if user.active and not user.suspended
]

Pythonic code is not code that uses every Python feature. Pythonic code is code whose intent survives the next change.

In 2026, the language has more expressive tools than it used to: structural pattern matching, TypeIs, deferred annotations, t-strings, better errors, and a growing set of runtime options. The standard should not be "new syntax everywhere." The standard should be "explicit at the boundaries, boring inside the core, and clever only when the cleverness buys a real system property."

Prefer Direct Transformations#

Comprehensions are often clearer than map and filter because they expose the output, the input, and the condition in one expression.

eligible_customers = [
    customer
    for customer in customers
    if customer.status == "active" and customer.balance_cents >= 0
]

The trap is turning comprehensions into a private language.

scores = {
    user.id: score(normalize(user), rules[region(user)])
    for user in users
    if user.active and region(user) in rules and not blocked(user)
}

This may still be correct. It is also doing too much work inside a dictionary literal. If any function call has side effects, cost, or failure behavior that deserves a name, give it one.

scores: dict[str, float] = {}
 
for user in users:
    if not user.active or blocked(user):
        continue
 
    user_region = region(user)
    if user_region not in rules:
        continue
 
    scores[user.id] = score(normalize(user), rules[user_region])

The tradeoff is line count. I will spend the lines when the branch policy matters.

Check None When You Mean None#

Truthiness is useful. It is also one of the easiest ways to blur domain meaning.

if not customer:
    return

That line rejects None, empty collections, false-y custom objects, and anything whose __bool__ says no. If the boundary means "missing customer," say it.

if customer is None:
    return

The failure mode is subtle in data systems. An empty string, 0, False, Decimal("0"), and an empty list may all be valid values. A truthiness check can turn "present but empty" into "missing." That is how a legitimate zero-dollar invoice becomes a skipped invoice or an empty retrieval result becomes a missing retrieval system.

Use truthiness for containers when emptiness is the point. Use identity checks when absence is the point.

Pattern Matching Belongs Where Shape Matters#

Structural pattern matching, specified in PEP 634, is at its best when dispatch depends on shape.

def route_tool_result(result: dict[str, object]) -> str:
    match result:
        case {"type": "search", "documents": [*documents]} if documents:
            return "summarize_documents"
        case {"type": "search", "documents": []}:
            return "ask_for_better_query"
        case {"type": "action", "status": "requires_approval"}:
            return "request_human_confirmation"
        case {"type": "action", "status": "completed"}:
            return "record_action"
        case {"type": result_type}:
            raise ValueError(f"unsupported tool result type: {result_type}")
        case _:
            raise ValueError("malformed tool result")

This is better than scattered key checks because each branch names a payload shape and a decision.

The mistake is using match as a decorative if.

match status:
    case "open":
        ...
    case "closed":
        ...

That may be fine, but it does not need pattern matching. A dictionary of handlers or an if chain may read better. Use match when destructuring is doing real work.

T-Strings Are for Template Consumers#

Python 3.14 added template string literals through PEP 750 and the string.templatelib module. A t-string produces a Template, not a final str, so a library can inspect interpolations before rendering.

That is useful at injection-prone boundaries: SQL builders, shell command builders, HTML renderers, structured logging, prompt renderers, and policy-controlled tool calls.

The rule I like is:

f-string the local message.
t-string the boundary API.

Use f-strings when the result is immediately consumed as a string and no external language is being constructed.

logger.info(f"processed {count} invoices")

Use a t-string when the receiving function is designed to process the template structure.

query = sql(t"select * from invoices where customer_id = {customer_id}")

The sql() function in that example is doing the important work. A t-string is not magic safety by itself. It gives the boundary code access to the static strings and interpolated values before concatenation. The renderer must still escape, bind, validate, or reject values correctly.

The tradeoff is compatibility. T-strings require Python 3.14+. They also require libraries that intentionally accept Template objects. Do not sprinkle them into application code and expect the ecosystem to infer your security policy.

Exceptions Should Name Domain Failure#

Generic exception handling is where production bugs go quiet.

try:
    sync_customer(customer_id)
except Exception:
    pass

This does not mean "resilient." It means "unknown failure discarded."

A better design names the domain failure and preserves context.

class CustomerSyncError(Exception):
    """Raised when the customer sync workflow cannot complete."""
 
 
class CustomerNotFoundError(CustomerSyncError):
    pass
 
 
class CustomerSyncRetryableError(CustomerSyncError):
    pass

Then the caller can make a real decision.

try:
    sync_customer(customer_id)
except CustomerNotFoundError:
    mark_skipped(customer_id, reason="not_found")
except CustomerSyncRetryableError as error:
    schedule_retry(customer_id, reason=str(error))

The failure I want to avoid is the broad except Exception around a whole workflow. It catches parsing bugs, database outages, programmer mistakes, cancellation, and expected business conditions as if they were the same thing. If a handler must catch broadly at a process boundary, it should log the exception, attach context, and re-raise or convert to a known failure result.

Python 3.14 also warns on control-flow exits from finally blocks through PEP 765. The reason is practical: return, break, or continue leaving a finally block can suppress an exception from the try. If cleanup code can erase the real failure, the system becomes harder to debug exactly when debugging matters.

A Style Contract#

I would put this small contract in a Python repo before debating taste in reviews:

This is not about making code look like a style guide. It is about making review cheaper. When everyone agrees on the boundary defaults, code review can focus on behavior.

The Close#

Python gives you many ways to be concise. Production systems need a smaller subset: the concise forms that make the next change easier.

Use comprehensions when they clarify. Use loops when policy wants names. Use match when shape matters. Use t-strings when a boundary renderer can enforce safety. Use domain exceptions when the caller needs a decision. Check None when absence is the only thing you mean.

The modern Pythonic move is still the old one: say the thing plainly enough that the system can keep saying it after the feature changes.