Make Output[T] covariant in Python SDK

[benesch]

In short, this allows subtyping to correctly "propagate" through an Output;
if Cow is a subtype of Animal, this commit makes it so Output[Cow] is
treated as a subtype of Output[Animal].

Without this change, users of the Python SDK occasionally contend with a
confusing error message that is resolved by adding a call to
.apply(lambda x: x) to satisfy mypy.

Touches #3767.
Fix #6843.

cc @lukehoban @t0yv0

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests.

Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR

Further commands available:

• /run-codegen - used to test the Pull Request against downstream codegen
• /run-docs-gen - used to test the Pull Request against documentation generation

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests.

Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR

Further commands available:

• /run-codegen - used to test the Pull Request against downstream codegen
• /run-docs-gen - used to test the Pull Request against documentation generation

[benesch]

On Wed, Jul 14, 2021 at 11:00 AM Josh Studt ***@***.***> wrote: If this is approved I'd like to do similar in the dotnet SDK :) Similarly, if this is approved, is there any reason to not do the same in Input<T>?

In Python, Input[T] is already covariant as a result of its definition as Union[T, Awaitable[T], 'Output[T]'].

[orionstudt]

@benesch Makes sense for python. I don't think it is already covariant in the dotnet SDK. Sorry I deleted my comment though, thought it made more sense to make it on the issue instead of your PR

[komalali]

/run-acceptance-tests

[github-actions]

Please view the results of the PR Build + Acceptance Tests Run Here

[pgavlin]

LGTM.

Should we also add a contravariant type variable for Inputs in a future change? cc @lukehoban @t0yv0 @komalali @justinvp

[t0yv0]

I was slightly scared to recommend going ahead with this as I don't feel I have a good handle on all the implications, but I guess we will find out now that it is in :)

Input[T] and Output[T] should both have the same variance (if any) imo, that'd be covariant, because T occurs in a positive position in both (contrast with a negative position in a function type e.g. T -> int).

[lukehoban]

I was slightly scared to recommend going ahead with this as I don't feel I have a good handle on all the implications, but I guess we will find out now that it is in :)

Are we running mypy as part of our build to catch any possible impacts of this?

[benesch]

Input[T] and Output[T] should both have the same variance (if any) imo, that'd be covariant, because T occurs in a positive position in both (contrast with a negative position in a function type e.g. T -> int).

Agree! pulumi.Input[T] is already working correctly (covariantly) by my read.

Are we running mypy as part of our build to catch any possible impacts of this?

The python/sdk library definitely gets a mypy run via the lint target. Not sure about downstream providers though.

[pgavlin]

Agree! pulumi.Input[T] is already working correctly (covariantly) by my read.

Perfect. Covariance and contravariance is something I've always struggled to keep straight.

[justinvp]

Note that we do look at the type hints at runtime and it was necessary to pass a definition for T to get_type_hints for it to work.

pulumi/sdk/python/lib/pulumi/_types.py

Lines 725 to 728 in 0bcca38

	# Additionally, include a value for "T", which is needed for Input and InputType.
	# We use the NoneType for the value of "T" because using TypeVar here doesn't work on Python 3.6
	# and it doesn't matter what the value is for our purposes.
	localns = {"Output": Output, "T": type(None)} # type: ignore

I think this was only needed for Input[T] and InputType[T] and was unrelated to Output[T]. The existing tests should cover us here, but I'm curious to see how running the examples with this change fairs. We may end up having to add a definition for T_co in the same way.