You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Generic inner classes sees type variable from outer class #3144
T = TypeVar('T')
class Outer(Generic[T]):
class Inner:
x: T # E: Invalid type "test.T" (correct)
def f(self, x: T) -> T: ... # ok (incorrect)
def g(self) -> None:
y: T # E: Invalid type "test.T" (correct)
I looks like the method f is understood as a generic method with an independent variable, for example reveal_type(Outer[int].Inner.f) shows def [T] (self: tst22.Outer.Inner, x: T`-1) -> T`-1. i.e. T is not bound to int here.
Anyway, I think this is confusing and worth prohibiting. One can just use another type variable to create a generic method.
A generic class nested in another generic class cannot use same type variables.
I understand that rule as saying T can't be used anywhere in the class definition of Inner. I think that's a good rule, and I want it to be applied to Inner.f.
Ahh I see, even though the variables are out of scope, they can be used to define a new generic function. That makes sense, and I no longer think it's a problem (although I agree it's slightly confusing).
The PEP is ambiguous about this exact example. When you're defining an inner class, it specifically blacklists the outer class's parameters as valid parameters for the inner one, but semantically the outer class's parameters are out of scope -- the inner class doesn't have an instance context for the outer class. In a method in the inner class, there's no guidance. It's still semantically outside the scope of the outer class, but the reasons for blacklisting it have not gone away. In #3113 I may be changing this behavior to be more like the one you describe as less confusing, @pkch, I'll import your test there and see.
On Apr 14, 2017, at 10:32 AM, Max ***@***.***> wrote:
@sixolet I would prohibit it both in the PEP and in mypy. I can propose the edit to the PEP.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Activity
ilevkivskyi commentedon Apr 9, 2017
I looks like the method
fis understood as a generic method with an independent variable, for examplereveal_type(Outer[int].Inner.f)showsdef [T] (self: tst22.Outer.Inner, x: T`-1) -> T`-1. i.e.Tis not bound tointhere.Anyway, I think this is confusing and worth prohibiting. One can just use another type variable to create a generic method.
pkch commentedon Apr 9, 2017
So is my understanding below correct?
According to PEP 484:
I understand that rule as saying
Tcan't be used anywhere in the class definition ofInner. I think that's a good rule, and I want it to be applied toInner.f.ilevkivskyi commentedon Apr 9, 2017
No, PEP has an explicit example showing what is prohibited.
pkch commentedon Apr 9, 2017
Ahh I see, even though the variables are out of scope, they can be used to define a new generic function. That makes sense, and I no longer think it's a problem (although I agree it's slightly confusing).
sixolet commentedon Apr 14, 2017
The PEP is ambiguous about this exact example. When you're defining an inner class, it specifically blacklists the outer class's parameters as valid parameters for the inner one, but semantically the outer class's parameters are out of scope -- the inner class doesn't have an instance context for the outer class. In a method in the inner class, there's no guidance. It's still semantically outside the scope of the outer class, but the reasons for blacklisting it have not gone away. In #3113 I may be changing this behavior to be more like the one you describe as less confusing, @pkch, I'll import your test there and see.
sixolet commentedon Apr 14, 2017
Ok, no #3113 does not change this behavior. But if we want to, I have the code loaded into my head for exactly how, now.
pkch commentedon Apr 14, 2017
@sixolet I would prohibit it both in the PEP and in mypy. I can propose the edit to the PEP.
sixolet commentedon Apr 14, 2017
sixolet commentedon Apr 17, 2017
#3113 now fixes this.