Repository navigation
PEP 695: Introduce in and out keywords for specifying variance #2724
Description
@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 positionIf 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.
Activity
erictraut commentedon Jul 22, 2022
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
inandoutin languages that employ call-site variance, but Python uses declaration-site variance, so variance can be reliably calculated.KotlinIsland commentedon Jul 22, 2022
This is wrong, Kotlin doesn't have inferred variance, it's explicit with
in/out. Kotlin also supports awherekeyword and clause.It also doesn't mention Dart, which uses
in/out, and doesn't support use site variance. (ref)erictraut commentedon Jul 22, 2022
Kotlin supports use-site variance, so
inandoutspecification 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 commentedon Jul 22, 2022
The pep doesn't mention sub types at all:
I like the explicit nature of Kotlin/Dart, just from the class def I can tell how I can use it.
KotlinIsland commentedon Jul 22, 2022
This is also wrong, Java doesn't infer variance, it's invariant by default and use sites can specify the variance with the
superandextendskeywords.KotlinIsland commentedon Jul 22, 2022
Dart, C# and typescript have
in/outand don't support use site variance.erictraut commentedon Jul 22, 2022
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.
[-]pep-695 should introduce `in` and `out` keywords for specifying variance[/-][+](🎁) pep-695 should introduce `in` and `out` keywords for specifying variance[/+]KotlinIsland commentedon Jul 22, 2022
If the variance is explicit, then it makes it impossible to accidentally break the api of a library
DetachHead commentedon Jul 22, 2022
i agree with @KotlinIsland that
in/outkeywords decrease cognitive load for developers. the typescript blog post where they discuss the feature seems to agree as well: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 commentedon Jul 22, 2022
I've opened #2725 to resolve some of the errors in the pep.
KotlinIsland commentedon Jul 22, 2022
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 commentedon Jul 22, 2022
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/
[-](🎁) pep-695 should introduce `in` and `out` keywords for specifying variance[/-][+]PEP 695: Introduce `in` and `out` keywords for specifying variance[/+]CAM-Gerlach commentedon Jul 22, 2022
In particular, it should go to the PEP's canonical discussion thread there — @erictraut , now that the PEP is live, could you link the appropriate thread in the
Discussions-Toheader, either the existing draft PEP thread or a new thread for the posted PEP, to help users find the canonical discussion (you'll also want to link that thread and any new thread you create under thePost-Historyheader)? Thanks!