Inconsistent behavior with accessing non-existent field

[smaye81]

I think the v0.3.0 release may have introduced a bug (or at least an inconsistency) with accessing a non-existent field. Consider the following expression:

dyn(this).b == 'foo'

Previously on v0.2.0, evaluating this expression with a binding of this to celtypes.MapType({"a": "foo"}) would result in an error:

# TypeError: no such overload: StringType('foo') <class 'celpy.celtypes.StringType'> != CELEvalError(*("no such member in mapping: 'b'", <class 'KeyError'>, None), tree='dyn(this).b') <class 'celpy.evaluation.CELEvalError'>

However, in v0.3.0, the evaluation proceeds and just returns false. Additionally, evaluating the expression has(this, 'b') against the same binding above, results in true which is definitely wrong.

The spec isn't entirely clear with a field selection expression, e.f when e evaluates to a map. For messages, it specifies a runtime error should be raised, but doesn't explicitly say that for maps. However, I would assume it should maybe behave the same way? The CEL implementations for Go, Java, and C++ all throw a runtime error. At the very least, it seems the has test is wrong.

I think this was introduced with https://github.com/cloud-custodian/cel-python/pull/94, although I can't say for sure. Definitely willing to help if this is indeed considered an issue.

I've also put up a repro to illustrate what I'm seeing: https://github.com/smaye81/cel-python-repro

[stefanvanburen]

I definitely think this is from #94, specifically dropping the @type_matched decorators on StringType.__{eq,ne}__.

Unfortunately, though, I think this is the right path (I started off dropping a lot of @type_matched decorators in #135, which helped pass a lot more of the conformance tests), but it seems like the way that the way exceptions are transformed into result values in certain situations causes other troubles in handling in the library, specifically when it comes to short circuiting evaluation.