From 724859d8508c48322101e8b2275d5c999d5361d9 Mon Sep 17 00:00:00 2001 From: Gil Forsyth Date: Mon, 27 Nov 2023 16:58:19 -0500 Subject: [PATCH] fix(deferred): don't pass expression in fstringified error message This is a weird one, BUT: - There is (at least) one case where, when trying to resolve a deferred value, we end up at the `CoercionError` exception with a non-deferred expression. When `ibis.options.interactive = True`, we then attempt to render that expression using `rich` because that's what f-strings do. Even though in the calling code, which here is in `CoercedTo.match`, we catch the `CoercionError`, the `CoercionError` never gets thrown because we've instead errored out trying to render an f-string that will never be seen. If, instead of rendering the expression, we instead mention the expression type, that prevents the short-circuit. --- ibis/common/deferred.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ibis/common/deferred.py b/ibis/common/deferred.py index 593cb3a09782..8061d0657758 100644 --- a/ibis/common/deferred.py +++ b/ibis/common/deferred.py @@ -51,7 +51,9 @@ def __coerce__(cls, value): elif isinstance(value, Deferred): return value._resolver else: - raise CoercionError(f"Cannot coerce {value!r} to {cls.__name__!r}") + raise CoercionError( + f"Cannot coerce {type(value).__name__!r} to {cls.__name__!r}" + ) class Deferred(Slotted, Immutable, Final):