[WIP] Add scoping rules for type variables to PEP 484 #63
Conversation
|
Hello, and thanks for your contribution! Unfortunately we couldn't find an account corresponding to your GitHub username at bugs.python.org (b.p.o). If you don't already have an account at b.p.o, please create one and make sure to add your GitHub username. If you do already have an account at b.p.o then please go there and under "Your Details" add your GitHub username. And in case you haven't already, please make sure to sign the PSF contributor agreement (CLA); we can't legally look at your contribution until you have signed the CLA. Once you have done everything that's needed, please reply here and someone will verify everything is in order. |
|
@the-knights-who-say-ni I have added my github username on bugs.python.org |
| Type variables follow normal name resolution rules. | ||
| However, there are some special cases in the static typechecking context: | ||
|
|
||
| * A type variable could be inferred to be equal to different types in a block, |
There was a problem hiding this comment.
This section feels unclear, though I'm not sure how to say it right myself.
The key point is that the occurrence of a type variable in a method signature can mean one of two things:
- a generic function;
- a method of a generic class.
The disambiguating rule is that if the class of which this is a method is generic over a type variable, then the type variable refers to the class's type parameter; if not, it is a "free" type variable, making the function generic. (I'm making up the term "free" here.)
The other rule, which you are describing in this same section, is that free type variables occurring in different functions are unconnected. (I think the example showing this should be shown first, separately, before discussing type variables belonging to a generic class.)
There was a problem hiding this comment.
I tried to reformulate this by splitting it into three separate rules. Please check if it is more clear now.
|
@gvanrossum The new version is ready for review now |
| y = x.method(0, "abc") # inferred type of y is str | ||
|
|
||
| * Unbound type variables should not appear in the bodies of generic functions, | ||
| and in the class bodies appart from method definitions:: |
|
That's all I have! |
|
@gvanrossum I implemented all the comments from the second review in the new version. |
Revise target file related terminology
Fixes python/typing#249
@gvanrossum please review