-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider allowing @final
methods in Protocols
#13310
Comments
If you are using protocols for mixins, why not ABCs? To me, OTOH ABCs also offer virtual registering and I didn't check mypy for whether |
With ABCs, there is the problem that I can't define abstract attributes, like the Yeah, virtual registering really is a strange feature. I feel like most people just pretend it doesn't exist. |
I feel like this should be separated into two parts: from typing import Protocol, final
class MySized(Protocol):
len: int
def __len__(self) -> int: ...
class _MyImpl:
def __len__(self) -> int:
return self.len
class MyClass(_MyImpl):
def __init__(self, len: int) -> None:
self.len = len I would prefer to keep |
If I'd like to share the default implementation across protocol implementations, does it mean I have to do something like this: import abc
from typing import Protocol, final
class MySized(Protocol):
len: int
def __len__(self) -> int: ...
class _MyDefaultImpl(abc.ABC, MySized):
@final
def __len__(self) -> int:
return self.len
class MyClass(_MyDefaultImpl):
def __init__(self, len: int) -> None:
self.len = len
MyClass(15) |
Feature
Allow this:
Pitch
I get that this is a bit unusual, but I don’t really see any harm that could come from this (as an aside,
pyright
allows it). My use case is that I’m usingProtocol
s for mixins, and sometimes I want to make sure my mixed-in methods don’t get overwritten.The text was updated successfully, but these errors were encountered: