Cope with defaults

[MarkSymsCtx]

If something like

volume_type: volume_type [@default Data]

where volume_type is

type volume_type =
  | Data (** Normal data volume *)
  | CBT_Metadata  (** CBT Metadata only, data destroyed *)
  | Data_and_CBT_Metadata  (** Both Data and CBT Metadata *)

and then the generator is run the Python code looks like

            if tmp_26['volume_type'][0] not in ["Data", "CBT_Metadata", "Data_and_CBT_Metadata"]:
                raise TypeError("| Data (unit) (** Normal data volume *) | CBT_Metadata (unit) (** CBT Metadata only, data destroyed *) | Data_and_CBT_Metadata (unit) (** Both Data and CBT Metadata *)", repr(tmp_26['volume_type']))

which then throws a KeyError if the value is not passed, which is obviously not the intent when placing an @default in the definition.

I think it should be using tmp_26.get('volume_type', "Data")[0] instead

[MarkSymsCtx]

Not sure there should be a [0] on it either.

Similarly something like cbt_enabled: bool [@default false] should also use get with the default being False

[MarkSymsCtx]

@mseri thinking about this some more, as it is "only" the validation code for the API responses it would probably be better as

    if '<key> in tmpXX:
        <existing code fragment>

There seems little point having the Python code do default substitution here when the return value isn't going to contain that data. But, only for those fields with an @default qualifier