-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[sdk/python] Improved dict key translation support #6695
Conversation
b52aa4c
to
41ffcc4
Compare
Diff for pulumi-random with merge commit 5f3985a |
Diff for pulumi-azuread with merge commit 5f3985a |
Diff for pulumi-kubernetes with merge commit 5f3985a |
Diff for pulumi-gcp with merge commit 5f3985a |
Diff for pulumi-azure with merge commit 5f3985a |
Diff for pulumi-aws with merge commit 5f3985a |
Diff for pulumi-azure-native with merge commit 5f3985a |
41ffcc4
to
2859072
Compare
a4ef273
to
1b38798
Compare
This change addresses Python dictionary key translation issues. When the type of `props` passed to the resource is decorated with `@input_type`, the type's and resource's property name metadata will be used for dict key translations instead of the resource's `translate_input_property` and `translate_output_property` methods. The generated provider SDKs will be updated to opt-in to this new behavior: - FIX: Keys in user-defined dicts will no longer be unintentionally translated/modified. - BREAKING: Dictionary keys in nested output classes are now consistently snake_case. If accessing camelCase keys from such output classes, move to accessing the values via the snake_case property getters (or snake_case keys). A warning will be logged when accessing camelCase keys. When serializing inputs: - If a value is a dict and the associated type is an input type, the dict's keys will be translated based on the input type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated. When resolving outputs: - If a value is a dict and the associated type is an output type, the dict's keys will be translated based on the output type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated.
2859072
to
6e2eca0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a question about the use of .items()
and whether we're certain we're not passing in any InputType
or OutputType
s there.
This change addresses Python dictionary key translation issues. When the type of `props` passed to the resource is decorated with `@input_type`, the type's and resource's property name metadata will be used for dict key translations instead of the resource's `translate_input_property` and `translate_output_property` methods. The generated provider SDKs will be updated to opt-in to this new behavior: - FIX: Keys in user-defined dicts will no longer be unintentionally translated/modified. - BREAKING: Dictionary keys in nested output classes are now consistently snake_case. If accessing camelCase keys from such output classes, move to accessing the values via the snake_case property getters (or snake_case keys). Generated SDKs will log a warning when accessing camelCase keys. When serializing inputs: - If a value is a dict and the associated type is an input type, the dict's keys will be translated based on the input type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated. When resolving outputs: - If a value is a dict and the associated type is an output type, the dict's keys will be translated based on the output type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated.
This change addresses Python dictionary key translation issues. When the type of `props` passed to the resource is decorated with `@input_type`, the type's and resource's property name metadata will be used for dict key translations instead of the resource's `translate_input_property` and `translate_output_property` methods. The generated provider SDKs will be updated to opt-in to this new behavior: - FIX: Keys in user-defined dicts will no longer be unintentionally translated/modified. - BREAKING: Dictionary keys in nested output classes are now consistently snake_case. If accessing camelCase keys from such output classes, move to accessing the values via the snake_case property getters (or snake_case keys). Generated SDKs will log a warning when accessing camelCase keys. When serializing inputs: - If a value is a dict and the associated type is an input type, the dict's keys will be translated based on the input type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated. When resolving outputs: - If a value is a dict and the associated type is an output type, the dict's keys will be translated based on the output type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated.
This change addresses Python dictionary key translation issues. When the type of `props` passed to the resource is decorated with `@input_type`, the type's and resource's property name metadata will be used for dict key translations instead of the resource's `translate_input_property` and `translate_output_property` methods. The generated provider SDKs will be updated to opt-in to this new behavior: - FIX: Keys in user-defined dicts will no longer be unintentionally translated/modified. - BREAKING: Dictionary keys in nested output classes are now consistently snake_case. If accessing camelCase keys from such output classes, move to accessing the values via the snake_case property getters (or snake_case keys). Generated SDKs will log a warning when accessing camelCase keys. When serializing inputs: - If a value is a dict and the associated type is an input type, the dict's keys will be translated based on the input type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated. When resolving outputs: - If a value is a dict and the associated type is an output type, the dict's keys will be translated based on the output type's property name metadata. - If a value is a dict and the associated type is a dict (or Mapping), the dict's keys will _not_ be translated.
This change addresses Python dictionary key translation issues. When the
type of
props
passed to the resource is decorated with@input_type
,the type's and resource's property name metadata will be used for dict
key translations instead of the resource's
translate_input_property
and
translate_output_property
methods.The generated provider SDKs will be updated to opt-in to this new
behavior:
FIX: Keys in user-defined dicts will no longer be unintentionally
translated/modified.
BREAKING: Dictionary keys in nested output classes are now
consistently snake_case. If accessing camelCase keys from such output
classes, move to accessing the values via the snake_case property
getters (or snake_case keys). Generated SDKs will log a warning
when accessing camelCase keys.
When serializing inputs:
If a value is a dict and the associated type is an input type, the
dict's keys will be translated based on the input type's property
name metadata.
If a value is a dict and the associated type is a dict (or Mapping),
the dict's keys will not be translated.
When resolving outputs:
If a value is a dict and the associated type is an output type, the
dict's keys will be translated based on the output type's property
name metadata.
If a value is a dict and the associated type is a dict (or Mapping),
the dict's keys will not be translated.
Example of opting-in to the new behavior:
Part of #3151
Codegen change: #6696