Hrmm, even though it's the case that this enumerate returned from describe/list happens to have the same values in a different format as the search attribute, not sure we want to guarantee that will always be the case. We intentionally document the explicit set of enumerate strings athttps://docs.temporal.io/search-attribute#default-search-attribute without reference to this enumerate, but it's technically possible that list could change unrelated to this enumerate (even if it happens to match today even in server code). Most (all?) parts of the list filter/query don't have non-string-literal representations in SDKs at this time.

Understandable, would it make more sense to have something as part of the search attributes then?

That way, you would not introduce a breaking change if you change the format and update the property/function? Just thought it seemed strange that your own types would not work as search attributes out of the box.

There are a couple of search attributes that have pre-defined enumerates (e.g.TemporalWorkflowVersioningBehavior in addition to this one), but the actual type is trulyKeyword which is a string. I think, in the absence of a type safe query builder or even a predefined set ofSearchAttributeKeys for all of the built-in search attributes, we currently recommend using the string format only for keys/values for list filters based on expectations in the doc instead of hardcoded SDK-side expectations.

We can keep an issue open for if/when we do decide to provide type safe assistance to building of list filters (not just enumerates, but the predefined typed key set,TemporalWorkerDeploymentVersion parsing, conditional/query building, string escaping, etc). And we would of course do it across every SDK for parity not just Python.