@JelleZijlstra, I think you wrote this test originally. Could you review the proposed change and let me know what you think?

Looks like@hauntsaninja wrote this in#1589.

The spec itself has a similar line inhttps://typing.python.org/en/latest/spec/generics.html#instantiating-generic-classes-and-type-erasure (look fortype(p).x). I'm sympathetic to allowing this but we should change the spec example too.

And in fact the example comes from PEP 484:https://peps.python.org/pep-0484/#instantiating-generic-classes-and-type-erasure

Yup, I added the test because of the relevant line in PEP 484 / the spec.

This PR makes sense given that none of pytype/pyre/mypy error here. I am sympathetic to the use case in the pyright discussion, since I can't think of a great alternative for the user. If we want to try and close down the hole introduced, we could consider erroring on assignment to such variables.

Ah good catch. I didn't see that in the spec. Yeah, we should probably fix this in the spec then. One way to do this is to simply delete that line in the example. I'm not sure we want to mandate or disallow an error in this case, so leaving it up to type checkers is probably the right answer.

@JelleZijlstra, do you think that deleting this line is a substantive enough change that we should go through the full process of soliciting feedback and having the full TC sign off on it? Or is it small enough that we can shortcut that process? I doubt it will be contentious.

I feel given that we're changing the output of something that has been explicitly specified to raise an error, this is a substantive change and should go through Council approval.