parser.expressions

Parse expression with ternary and null coalescing.

Filters are handled at higher precedence (in _parse_unary_postfix). Null coalescing (??) has lowest precedence (below or).

Parse null coalescing: a ?? b.

Returns b if a is None/undefined, otherwise a. Right-associative: a ?? b ?? c = a ?? (b ?? c) Part of RFC: kida-modern-syntax-features.

Parse ternary conditional: a if b else c

Jinja2 also supports short form: a if b (defaults to '' if false)

The condition can include filters because filters have higher precedence than comparisons: x if y | length > 0 else z

Parse null coalescing without ternary support.

Used in for loops where we need ?? but not ternary (to preserve inline if): {% for x in items ?? [] %} ← works {% for x in items if x.visible %} ← still works

Part of RFC: kida-modern-syntax-features.

Check if current token can start a test argument without parens.

Used for: is sameas False, is sameas None Only allow simple values to avoid ambiguity with following expressions.

Parse addition/subtraction/concatenation.

The ~ operator is string concatenation in Jinja.

Parse multiplication/division with filter chain.

Filters are applied after multiplication but before addition:

a + b | filter parses as a + (b | filter) a * b | filter parses as (a * b) | filter -42 | abs parses as (-42) | abs → 42

Parse unary operators.

Unary operators bind tighter than filters:

-42|abs parses as (-42)|abs → 42

Parse primary expressions with postfix operators (., [], (), ?., ?[).

Does NOT include filter operator (|) - filters are parsed at a lower precedence level in _parse_filter_chain.

Supports optional chaining: ?. and ?[ (RFC: kida-modern-syntax-features).

Parse range literal after seeing start value.

Syntax:

1..10    → inclusive range [1, 10]
1...11   → exclusive range [1, 11) (like Python range)
1..10 by 2  → range with step

Part of RFC: kida-modern-syntax-features.

Parse filter chain: expr | filter1 | filter2(arg).

Also handles pipeline operator: expr |> filter1 |> filter2(arg).

Design: Mixing | and |> in the same expression is not allowed. The first operator encountered determines the style for the expression.

Filters are parsed after unary operators:

-42|abs parses as (-42)|abs → 42

Parse pipeline chain: expr |> filter1 |> filter2(arg).

Pipelines are left-associative: a |> b |> c == (a |> b) |> c

Each step is a filter application. The pipeline collects all steps into a single Pipeline node for potential optimization.

Design: Mixing | and |> is not allowed. Error on | after |>.