A broader name -> type concept

(I’m assuming you mean implicit types and not explicit types)

I don’t understand how that is relevant to the conversation. Either you misunderstand me or I misunderstand you. In my understanding, static typing in python is totally orthogonal to any runtime checks. With or without type checking, the code example you gave should be exactly the same?

As I understand you, this is directly related so I may not understand you much. My understanding of your example is that normally, request.user is typed as Any meaning that it could be anything. Type checkers would not know what it is, which is why you are explicitly stating that it is User type rather than relying on existing upstream type hints.

In the case that the request.user attribute is typed as Any, the type-safe way of narrowing the definition as actually being User in a type checker is to use type-narrowing as described in mypy’s documentation rather than an explicit annotation : User.

Thus, while the two are orthogonal in concept, one uses runtime to prove that your type information is right as opposed to telling it what it is without proof that it actually is that.

What I took away from the post was a desire for a way to avoid type narrowing by instead explicitly stating the type, overriding the need for that proof. I certainly could be misunderstanding though, have a newborn so I’m a bit low on sleep. Apologies if that’s the case and thanks for your patience. Hopefully this explanation helps clarify why I feel this example relates

Yea you have misunderstood. This proposal is just a way to centralize all user: User annotations to a config file in one place instead of every place a variable “user” is mentioned.

The behavior at runtime and at static check time would be unchanged.