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
- Reorder the conversion through supported hops (str -> int -> float, or via Json accessors) instead of one direct convert
- Do the conversion inside a UDF where you control the python-level coercion, and annotate the supported return dtype
- 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
- Chain conversions through supported intermediate dtypes instead of one exotic jump
- Prefer UDFs with annotated return types for non-standard conversions
- Keep Optional/unwrap usage aligned with converters that actually exist
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
- Pathway does not support using binary operator {expression._
- Pathway doesn't support casting {source_type} to {target_typ
- Column of type {dtypes[0]} has no attribute {expression._nam
- Cannot flatten column of type {dtype}.
- Unsupported type {input_type}, use pw.DATE_TIME_UTC or pw.DA
AI-assisted analysis of pathwaycom/pathway@fa2f74a464 (2026-08-15).
Data as JSON: /api/errors/f32daac9bf614235.
Report an issue: GitHub.