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

Only concrete class can be decorated with @total_ordering #8539

Closed
mthuurne opened this issue Mar 14, 2020 · 4 comments
Closed

Only concrete class can be decorated with @total_ordering #8539

mthuurne opened this issue Mar 14, 2020 · 4 comments
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code priority-1-normal topic-runtime-semantics mypy doesn't model runtime semantics correctly

Comments

@mthuurne
Copy link
Contributor

mthuurne commented Mar 14, 2020

When I check this code with mypy:

from abc import abstractmethod
from functools import total_ordering

@total_ordering
class PriorityMixin:

    @abstractmethod
    def getName(self) -> str: ...

    @abstractmethod
    def getPriority(self) -> int: ...

    def __hash__(self) -> int:
        return hash(self.getName())

    def __eq__(self, other: object) -> bool:
        if isinstance(other, PriorityMixin):
            return self.getName() == other.getName()
        else:
            return NotImplemented

    def __lt__(self, other: object) -> bool:
        if isinstance(other, PriorityMixin):
            prioCmp = self.getPriority() - other.getPriority()
            if prioCmp == 0:
                return self.getName() < other.getName()
            else:
                return prioCmp < 0
        else:
            return NotImplemented

It reports:

testcase.py:4: error: Only concrete class can be given where "Type[PriorityMixin]" is expected  [misc]
    @total_ordering
     ^

I'm using mypy 0.770 under Python 3.7.3 on openSUSE Linux.

I don't see a reason why an abstract class cannot be decorated with @total_ordering.

In typeshed commit e404e15 the signature of total_ordering was changed to preserve the original type. I think that change makes sense until full total_ordering support is implemented (#4610), but it does trigger the issue described above.

I think this issue may be a variation of #5374, since that describes a similar problem when using @dataclass as an annotation.

@mthuurne mthuurne changed the title Only concrete class can be annotated with @total_ordering Only concrete class can be decorated with @total_ordering Mar 14, 2020
@JukkaL JukkaL added bug mypy got something wrong false-positive mypy gave an error on correct code priority-1-normal labels Mar 20, 2020
@JukkaL
Copy link
Collaborator

JukkaL commented Mar 20, 2020

Yeah, this looks like a bug. The best fix might be to generally relax the requirement to have a concrete class as a type object.

@jakob-keller

This comment has been minimized.

@mthuurne
Copy link
Contributor Author

I am experiencing the same issue with mypy 0.770, whereas this appears to pass in 0.761. Maybe the root cause may be narrowed down to a regression introduced in 0.770.

That's because of the new typeshed that's included with mypy 0.770. The change in typeshed is not the root cause though, it only exposed the existing limitation in mypy.

@AlexWaygood AlexWaygood added the topic-runtime-semantics mypy doesn't model runtime semantics correctly label Mar 29, 2022
@erictraut
Copy link

This bug appears to have been fixed at some point. I'm not able to repro it with the latest version of mypy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code priority-1-normal topic-runtime-semantics mypy doesn't model runtime semantics correctly
Projects
None yet
Development

No branches or pull requests

6 participants