Fixes for covariance/contravariance + #734 #898
Conversation
We weren't actually passing in the variance, instead we were passing in line as the value and letting line get defaulted. As a possible fix for things like this not happening in the future, invariance really should be an enum, not an int. Otherwise, we don't get protected by the type system we are making...
Reject covariant type variables being used as an argument type. Reject contravariant type variables being used as a return type. Fixes python#734.
|
The implementation for #734 provides test coverage for the first fix so I decided to include these together |
|
I have a followup for this that adds checks for inheritance-related variance issues, but because github's model doesn't allow me to submit a PR for commits based on things that aren't in your repository yet, I'll wait until this is merged... |
|
If you submit a PR with (all the commits in one PR) + (all the commits in another PR), then if the first PR is merged, they'll disappear frrom the second PR. I've done that with several of my PRs, though I have to be careful with rebasing them all over the weeks and months that they aren't merged. |
|
I generally prefer if you can wait until the first PR is merged if you have a second PR on top of that, as things can get very confusing when sending a pull request on top another one that hasn't been merged, especially if the first one requires significant changes based on the review. |
|
Thanks for the PR, looks good! As mentioned in #734, things like |
Fixes for covariance/contravariance + #734
We weren't actually propagating variance to the
TypeVarTypecorrectly.Fixes this and also #734 which was my end goal when writing this small series.