The enum docstrings added above suggest that order is significant. However,frozenset is unordered: if the ordering is signifcant, then we should be preserving it -- maybe return a tuple to preserve the order?

As perdocs, the order is not significant, which why a (frozen) set is returned.

The order of the types in this field is ignored.

The backend always uses the following order: NUMERIC, BIGNUMERIC, and STRING (among the target types provided). I'll re-read the enum docstrings and make them more clear, if necessary.

So we are storing it as a list in the setter for compatibility with how the back-end sends it to us?

It's primarily because sets are not JSON serializable out of the box -json.dumps() usesJSONEncoder by default, but the latter doesn't know how to serialize sets.

@shollyman TheDecimalTargetType enumdocs can be misleading if not knowing the entire context. That"Depending on the order" bit might be understood as if the order matters when providing a list of target decimal types, thus I removed it from the Python class docstrings.

Should the generated docs follow suit? Or perhaps modify the wording?

Hi Peter, yes I can see how the doc contradicts the disco doc description. Checking w backend guy right now. Will update shortly.

"disco doc" - gotta love that lingo. ❤️ 🎊 🤣

Upon checking w myzhong@, the order actually does not matter here. It would always go for NUMERIC if it's possible even if user specified ["BIGNUMERIC", "NUMERIC"].https://cloud.google.com/bigquery/docs/reference/rest/v2/Job says "The order of the types in this field is ignored" and is accurate.

OK thanks, we'll keep the target types in afrozenset then. We should probably reword the generated enum docs, though.

b/193235792 created to track the doc update. cl/383854927 created to update the doc. Pending review from BQ techwriters.

I notice we are missing docs for a bunch of enums. I filed#744 to switch the docs over to module-based docs for this module.