Skip to content
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

Merged
merged 4 commits into from
Apr 6, 2021

Conversation

justinvp
Copy link
Member

@justinvp justinvp commented Apr 2, 2021

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:

# A <Resource>Args class decorated with `@input_type` with type/name metadata for the resource's
# top-level inputs.
@pulumi.input_type
class FooArgs:
    def __init__(self, some_value: pulumi.Input[str]):
        pulumi.set(self, "some_value", some_value)

    @property
    @pulumi.getter(name="someValue")
    def some_value(self) -> pulumi.Input[str]:
        return pulumi.get(self, "some_value")

class Foo(pulumi.CustomResource):
    def __init__(__self__, resource_name: str, args: FooArgs, opts: pulumi.ResourceOptions):
        # An instance of <Resource>Args is passed for `props`. Since it is decorated with
        # `@input_type` this opts-in to using the input type and the resource's
        # type/name metadata for dict key translations, rather than calling
        # `translate_input_property` and `translate_output_property`.
        super().__init__(__self__, "example::Foo", args, opts)

Part of #3151
Codegen change: #6696

@justinvp justinvp force-pushed the justin/python_translate branch 3 times, most recently from b52aa4c to 41ffcc4 Compare April 5, 2021 13:42
@justinvp justinvp changed the base branch from master to feature-3.0 April 5, 2021 13:42
@justinvp justinvp marked this pull request as ready for review April 5, 2021 13:44
@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-random with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-azuread with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-kubernetes with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-gcp with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-azure with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-aws with merge commit 5f3985a

@github-actions
Copy link

github-actions bot commented Apr 5, 2021

Diff for pulumi-azure-native with merge commit 5f3985a

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.
Copy link
Member

@komalali komalali left a 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 OutputTypes there.

sdk/python/lib/pulumi/resource.py Outdated Show resolved Hide resolved
sdk/python/lib/pulumi/runtime/rpc.py Show resolved Hide resolved
@justinvp justinvp merged commit e193d58 into feature-3.0 Apr 6, 2021
@pulumi-bot pulumi-bot deleted the justin/python_translate branch April 6, 2021 19:25
stack72 pushed a commit that referenced this pull request Apr 13, 2021
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.
stack72 pushed a commit that referenced this pull request Apr 14, 2021
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.
stack72 pushed a commit that referenced this pull request Apr 14, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants