PEP 695: Introduce `in` and `out` keywords for specifying variance

[KotlinIsland]

@erictraut Many other languages (including the beloved TypeScript) have keywords for specifying generic variance of in and out. I think it would be beneficial to introduce these for Python as well.

An analysis of other languages are detailed in the pep here, but it contains some factual errors which are being addressed in PR #2725 .

proposal:

class A[in I, out O]:
    def f1(self) -> I: ...  # error: contravariant TypeVar used in an output position
    def f2(self, t: O): ...  # error: covariant TypeVar used in an input position

If the variance is explicit, then it makes it impossible to accidentally break the api of a library.

To be consistent with other languages (except the beloved TypeScript) , I would expect these to be mandatory and all generics should default to being invariant.

I agree with the beloved TypeScript maintainers that explicit variance not only increase readability/reduce cognitive load, but I also believe that they increase discover-ability of generic variance. Also TypeScript is the only language I know of that infers the variance of type parameters.

If variance is a hidden/inferred property, then I believe it will lead to the "common user" being stricken with confusion when they encounter it, explicit keywords make it much more consumable.

I know experienced TypeScript developers that do not completely understand variance, due to it being implicitly inferred.

Read the typing-sig thread here

[erictraut]

This has been discussed in the typing-sig. Please refer to Appendix A for a survey of other languages. Contrary to what you've said, most languages do not require the specification of variance and do not provide a way to specify it explicitly. It introduces additional cognitive burden on language users, so absent a strong justification for including it, we should not include this. In all the discussions so far, we haven't identified such a reason.

There is some justification for including in and out in languages that employ call-site variance, but Python uses declaration-site variance, so variance can be reliably calculated.

[KotlinIsland]

This is wrong, Kotlin doesn't have inferred variance, it's explicit with in/out. Kotlin also supports a where keyword and clause.

It also doesn't mention Dart, which uses in / out, and doesn't support use site variance. (ref)

[erictraut]

Kotlin supports use-site variance, so in and out specification provides value. Python uses declaration-site variance only, and variance can be calculated from the declaration. Why would you want to force (or even allow) programmers to specify something that can be reliably calculated by the tools?

[KotlinIsland]

The pep doesn't mention sub types at all:

class A[T]:
    def foo(self) -> T: ...

class B[T](A[T]):  # is this an error?
    def bar(self, t: T): ...

I like the explicit nature of Kotlin/Dart, just from the class def I can tell how I can use it.

[KotlinIsland]

This is also wrong, Java doesn't infer variance, it's invariant by default and use sites can specify the variance with the super and extends keywords.

[KotlinIsland]

Kotlin supports use-site variance, so in and out specification provides value

Dart, C# and typescript have in / out and don't support use site variance.

[erictraut]

I like the explicit nature of Kotlin/Dart

OK, thanks for your input.

I don't think most share your view on this matter. I definitely don't. Unnecessarily increasing cognitive load for developers is generally undesirable.

[KotlinIsland]

If the variance is explicit, then it makes it impossible to accidentally break the api of a library

[DetachHead]

I don't think most share your view on this matter. I definitely don't. Unnecessarily increasing cognitive load for developers is generally undesirable.

i agree with @KotlinIsland that in/out keywords decrease cognitive load for developers. the typescript blog post where they discuss the feature seems to agree as well:

One reason is that it can be a useful for a reader to explicitly see how a type parameter is used at a glance. For much more complex types, it can be difficult to tell whether a type is meant to be read, written, or both.

i'm on the fence as to whether or not they should be mandatory. i understand the reasoning behind wanting them to be inferred, but i definitely think we should have the option specify them explicitly.

[KotlinIsland]

I've opened #2725 to resolve some of the errors in the pep.

[KotlinIsland]

I agree that explicit variance not only increase readability/reduce cognitive load, but they also increase discover-ability of generic variance.

I know experienced TypeScript developers that do not completely understand variance, due to it being implicitly inferred.

[hugovk]

Discussions about this PEP should go to the typing-sig mailing list (defined in the Discussions-To header).

https://mail.python.org/archives/list/typing-sig@python.org/