Why is Pulumi typing resource arguments using @pulumi.input_type-decorated SomethingArgs classes instead of a simple TypedDict? TypedDict are much lighter to use and would allow arguments composition the same way we can do using the args objects in TypeScript. Am I missing something?

would be great to have an issue opened

I'd be happy to. But I'm not sure what I should communicate. There is nothing wrong with the way things are done, it's just surprisingly complicated. I spent some time playing around with Python typing, trying to reproduce the pattern I'm used to in TypeScript. Not pretty, but does the job:

args = ClusterArgs(cluster_ipv4_cidr="1.2.3.4")
Cluster("composition", ClusterArgs(**args.__dict__, description="blah"))

(type checking is enforced) pyright catches this mistake:

args = {"x": 42}
ClusterArgs(**args, description="blah")

The only issue I've found (and that I do not understand), is that pyright doesn't catch the issue when mixing different "args objects":

ClusterArgs(**ClusterReleaseChannelArgs(channel="foo").__dict__)

Of course, this fails at runtime with a TypeError:

>>> ClusterArgs(**ClusterReleaseChannelArgs(channel="foo").__dict__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ClusterArgs.__init__() got an unexpected keyword argument 'channel'

just opening an issue with the desired way you’d like it done would be helpful

I did my best to express my frustrations, attempts and ideas, but I am not sure it's very helpful: https://github.com/pulumi/pulumi/issues/11732

In AWS CDK they took the approach to convert the corresponding args structure to keyword parameters instead. I think that works better than the Args classes, but they do not have the equivalent of the options structure - there is only a single parent/scope parameter instead. It would be nice if something like TypedDict can work out in practice.

Pulumi also implements the keyword arguments approach.

We've had a few conversations about ways to improve the Python API experience - I've written down a good number of my thoughts, but I'm happy to see this conversation happening here. For historical reference, the reason we don't currently have a

TypedDict

interface available is that it was not supported in Python 3.6 (which is now EOL, so we don't need to adhere to its support contracts). There were some issues with optional keys in

TypedDict

as well, but upon taking a look at it now, it seems like those may have been resolved with

NotRequired

. Always happy to give this another look~

For historical reference, the reason we don't currently have a

TypedDict

interface available is that it was not supported in Python 3.6

That's what I expected. 🙂

There were some issues with optional keys in

TypedDict

as well, but upon taking a look at it now, it seems like those may have been resolved with

NotRequired

.

NotRequired is included in 3.11 and available in https://pypi.org/project/typing-extensions/