Skip to content
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

object.__eq__ should only allow Self as the other argument #451

Open
DetachHead opened this issue Jun 25, 2024 · 1 comment
Open

object.__eq__ should only allow Self as the other argument #451

DetachHead opened this issue Jun 25, 2024 · 1 comment
Labels
based non-standard/breaking change (eg. would cause issues in 3rd party code) type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules

Comments

@DetachHead
Copy link
Owner

could this be fixed by updating the __eq__ from object to only allow Self:

def __eq__(self, __value: Self) -> bool: ...

because currently since it takes object no subtypes can override it with something more specific. your example currently doesnt work for that reason:

class SupportsEq(Protocol[T]):
    @override
    def __eq__(self, other: T) -> bool: ... # error: error: Argument 1 of "__eq__" is incompatible with supertype "object"; supertype defines the argument type as "object"

but if object's __eq__ used the Self type, then a subtype could just do this and there'd be no issue:

class A:
    @override
    def eq(self, other: Self | int) -> bool: ...

Originally posted by @DetachHead in KotlinIsland/basedmypy#574 (comment)

@DetachHead DetachHead changed the title object.__eq__ should only allow Self as the other argument: object.__eq__ should only allow Self as the other argument Jun 25, 2024
@DetachHead DetachHead added based non-standard/breaking change (eg. would cause issues in 3rd party code) type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules labels Jun 25, 2024
@DetachHead
Copy link
Owner Author

probably related: #391

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
based non-standard/breaking change (eg. would cause issues in 3rd party code) type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules
Projects
None yet
Development

No branches or pull requests

1 participant