pathwaycom/pathway · error · TypeError

Pathway doesn't support converting {source_type} to {target_

Error message

Pathway doesn't support converting {source_type} to {target_type}.

What it means

eval_convert implements the type-conversion expression (used by .retag/declare/unwrap pipelines and the `convert` mechanism behind casts with a default). After skipping no-op conversions (equivalent dtypes, NONE->Optional, target Any), it looks up get_convert_operator for the (source, target, unwrap) combination; when none is registered it raises this TypeError, meaning that conversion path is not implemented.

Source

Thrown at python/pathway/internals/graph_runner/expression_evaluator.py:605

        source_type = expression._expr._dtype
        target_type = expression._return_type

        if (
            dt.dtype_equivalence(target_type, source_type)
            or dt.dtype_equivalence(dt.Optional(source_type), target_type)
            or (source_type == dt.NONE and isinstance(target_type, dt.Optional))
            or target_type == dt.ANY
        ):
            return expr

        if (
            result_expression := get_convert_operator(
                expr, default, source_type, target_type, unwrap
            )
        ) is not None:
            return result_expression

        raise TypeError(
            f"Pathway doesn't support converting {source_type} to {target_type}."
        )

    def eval_declare(
        self,
        expression: expr.DeclareTypeExpression,
        eval_state: RowwiseEvalState | None = None,
    ):
        return self.eval_expression(expression._expr, eval_state=eval_state)

    def eval_coalesce(
        self,
        expression: expr.CoalesceExpression,
        eval_state: RowwiseEvalState | None = None,
    ):
        dtype = self.expression_type(expression)
        args: list[api.Expression] = []
        for expr_arg in expression._args:

View on GitHub (pinned to fa2f74a464)

Solutions

  1. Reorder the conversion through supported hops (str -> int -> float, or via Json accessors) instead of one direct convert
  2. Do the conversion inside a UDF where you control the python-level coercion, and annotate the supported return dtype
  3. Drop the default/unwrap flags and handle failure rows explicitly with pw.if_else / filter so the registered converter path applies

Example fix

// before
value = pw.this.col.cast(str, default='')  # unsupported pair, e.g. bytes->str with default
// after
@pw.udf(return_type=str)
def to_str(v: bytes | None) -> str:
    return '' if v is None else v.decode('utf-8', 'replace')

value = to_str(pw.this.col)
Defensive patterns

Strategy: fallback

Validate before calling

SUPPORTED_CONVERSIONS = {(int, float), (float, int)}

def convert_supported(src, dst) -> bool:
    return (src, dst) in SUPPORTED_CONVERSIONS

Try / catch

try:
    expr.cast(dst, default=d)
except TypeError as e:
    if "support converting" in str(e):
        # fallback: do the conversion in a UDF with explicit error handling
        ...

Prevention

When it happens

Trigger: Using .cast(default=...) / convert-style expressions between dtype pairs with no registered converter (e.g. str->bytes with default, Json->int, bool->str); conversions crossing Optional boundaries with unwrap=True where the inner pair is unsupported.

Common situations: Calling API surfaces that route through ConvertExpression (type declarations with defaults, unwrap chains) on exotic dtype pairs; assuming every cast-with-fallback combination exists because plain cast works for some pairs.

Related errors


AI-assisted analysis of pathwaycom/pathway@fa2f74a464 (2026-08-15). Data as JSON: /api/errors/f32daac9bf614235. Report an issue: GitHub.