0.930 still gives me "inheriting final" error with an enum.Flag subclass

[achimnol]

Bug Report

#11579 seems to fix #11578 in the 0.930 release, but still there are edge cases.

To Reproduce

Here is a minimal reproduction example.

import enum


class StringSetFlag(enum.Flag):

    def __eq__(self, other):
        return self.value == other

    def __hash__(self):
        return hash(self.value)

    def __or__(self, other):
        if isinstance(other, type(self)):
            other = other.value
        if not isinstance(other, (set, frozenset)):
            other = set((other,))
        return set((self.value,)) | other

    __ror__ = __or__  # this line makes the error


class MyFlags(StringSetFlag):
    X = "x"
    Y = "y"

Expected Behavior

It should be accepted in type check.

Actual Behavior

test-enum.py:22: error: Cannot inherit from final class "StringSetFlag"
Found 1 error in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 0.930
• Mypy command-line flags: python -m mypy test-enum.py
• Mypy configuration options from mypy.ini (and other config files):

[mypy]
ignore_missing_imports = true
mypy_path = stubs,src
namespace_packages = true
explicit_package_bases = true

• Python version used: 3.9.7
• Operating system and version: Ubuntu 20.04 (amd64)

[sobolevn]

This one is tricky: __ror__ = __or__
Thank you! I will try to fix it tomorrow.

[A5rocks]

For what it's worth, I've seen others run into this: hikari-py/hikari@d145703#diff-f9118e96adf8379957f11aaba55186744ddfd128aa04bd0929c02ea55325c46cL66-R81

[sobolevn]

Ok, this one is quite complex. The problem is: we don't know most of the time what rhs is during the semantic analysis (value vs method). So, there are several options:

1. Try to move quite a lot of logic into TypeChecker, this can be quite problematic
2. Check .node type of rhs values. Allow FuncBase and Decorator. This can still generate some false-positives for tricky parts where functions are defined by regular variables, but are injected as methods.

I hope that the amount of false-positives in 2. will be so low, that we can ignore them.

[bew]

Hello, I'm hitting the same error for the same kind of reason, we have a base enum class where we override __eq__ implementation to be case insensitive:

class StringEqualityEnum(Enum):
    # necessary, as overriding __eq__ discards the __hash__ implementation in Enum.
    __hash__ = Enum.__hash__

    def __eq__(self, rhs: Any):
        if isinstance(self.value, str) and isinstance(rhs, str):
            return self.value.lower() == rhs.lower()
        return self is rhs

An easy workaround is to make it a function:

class StringEqualityEnum(Enum):
    def __hash__(self):
        # necessary, as overriding __eq__ discards the __hash__ implementation in Enum.
        return Enum.__hash__(self)

    def __eq__(self, rhs: Any):
        if isinstance(self.value, str) and isinstance(rhs, str):
            return self.value.lower() == rhs.lower()
        return self is rhs

I think setting __hash__ directly on the class should work though.

[sobolevn]

Ok, there are a lot more rules that we don't support at the moment: https://github.com/python/cpython/blob/549e62827262264cda30455e10e315602129da72/Lib/enum.py#L1538

For example, this will also raise a false-positive:

from enum import Enum

class HashEnum(Enum):
    __p__ = 1

class Other(HashEnum):
    pass

Runtime is fine, but type-checker is not: error: Cannot inherit from final class "HashEnum"

[sobolevn]

Ok, the only way to solve this is to move this logic to TypeChecker 😞

My decision to have this in SeamanticAnalyzer was wrong, sorry for all the inconvenience it caused!

[RJPercival]

How long will it be until this is fixed? It's causing hundreds of mypy errors in my project, making it impossible to upgrade to the latest release, which unfortunately I need as it contains the fix for #11456. If a fix will take some time, can this change to make enums final be reverted in the meantime? Alternatively, could it be made possible to disable this specific check without peppering hundreds of # type: ignore[misc] comments throughout my codebase?

[flaeppe]

Not sure if it's worth a new issue or not. But out of curiosity, should there be support for overriding e.g. dunder-attributes? Below doesn't typecheck, but is fine during runtime.

from enum import Enum


class BaseEnum(Enum):
    __something__ = 3


class SomeEnum(BaseEnum):
    __something__ = 2

error: Cannot override final attribute "__something__" (previously declared in base class "BaseEnum")

[sobolevn]

@flaeppe this is another issue 🙂
But, yes, we should also apply similar rules to what attributes are considered final.
Can you please open a new issue?

[flaeppe]

@sobolevn Alright, I've opened #12132