Suggest making protocol attribute read-only if invariance causes conflict

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.

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

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.

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.

Maybe we could support syntax like:

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

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?

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.

Use a property to define `Jsonlibrary`

Use a property to define `JsonLibrary` (#57)

Tweak DBAPI2 Protocol to be accepted by mypy 1.0

Use mypy 1.0 (#15052)

Maybe we could support syntax like:
class User(Protocol):
    email: Final[str]

Looks like this works in Pyright. It'll be nice to have this in Mypy too (or a different keyword to indicate read-only in Protocol).

The @property decorator is not optimal because it doesn't allow class-level access. Pyright considers it an error, while Mypy types it as property.fget — an unbound method. This is a problem when the protocol member is a descriptor with distinct behaviour for class-level access.

I'm looking to make my second contribution after my PR for #8874. I'll look at the existing covariant collection note as a model for the implementation.

Navigation Menu

Repository navigation

Suggest making protocol attribute read-only if invariance causes conflict #6002

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Suggest making protocol attribute read-only if invariance causes conflict #6002

Description

Activity

ilevkivskyi commented on Dec 4, 2018

petergaultney commented on Nov 6, 2019

ilevkivskyi commented on Nov 6, 2019

JelleZijlstra commented on Nov 6, 2019

petergaultney commented on Nov 6, 2019

ilevkivskyi commented on Nov 6, 2019

jace commented on Dec 27, 2023

yourlocaljosh commented on Apr 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions