Suggest making protocol attribute read-only if invariance causes conflict

[JukkaL]

If a concrete attribute has a narrower type than protocol attribute, mypy will complain (adapted from #5998):

prog.py:59: error: Argument 1 to "f" has incompatible type "C"; expected "Proto"
prog.py:59: note: Following member(s) of "C" have conflicts:
prog.py:59: note:     name: expected "Optional[str]", got "str"

It could help if mypy would suggest making the protocol attribute read-only (property or final attribute), which is often the right thing to do.

We already generate a related suggestion to use a covariant collection type when using an invariant collection causes type incompatibility.

[ilevkivskyi]

We can also add a link to the docs (again, similarly to the invariant collection note).

[petergaultney]

What are the chances that there will someday be a less verbose way of declaring a Protocol attribute read-only?

moving from

class User(Protocol):
    email: str

to

class User(Protocol):
    @property
    def email(self) -> str: ...

is quite painful in terms of readability, especially when you've got 10 or so attributes that should all be considered read-only.

[ilevkivskyi]

What are the chances that there will someday be a less verbose way of declaring a Protocol attribute read-only?

I would say chances are low, but theoretically non-zero.

[JelleZijlstra]

Maybe we could support syntax like:

class User(Protocol):
    email: Final[str]

[petergaultney]

I would love that. I tried it but of course Protocols don't support it currently.

I assume the hesitation there is around the fact that Final in its other contexts means that the value is assigned at class/module definition time, rather than at the time of object instantiation?

[ilevkivskyi]

I assume the hesitation there is around the fact that Final in its other contexts means that the value is assigned at class/module definition time, rather than at the time of object instantiation?

More because being final and being read-only are different concepts: a read-only attribute can be overridden in a subclass, a final one can't. Final is a stronger concept.

The notion of being final is in fact already quite complex (and has subtle differences in different languages), I don't want to overload it even more.