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

Enum elements accessed via 'self' have 'auto' type #12107

Open
finite-state-machine opened this issue Jan 31, 2022 · 4 comments
Open

Enum elements accessed via 'self' have 'auto' type #12107

finite-state-machine opened this issue Jan 31, 2022 · 4 comments
Labels
bug mypy got something wrong priority-2-low topic-enum

Comments

@finite-state-machine
Copy link

Bug Report

Within an Enum class e.g., SomeEnum, elements initialized with auto() and accessed as self.SOME_ELEMENT have type enum.auto* instead of SomeEnum, resulting in false positives for comparison operations.

To Reproduce

Run mypy on the following code:

from enum import (
        auto,
        Enum,
        )

class Game(Enum):

    TENNIS = auto()
    PING_PONG = auto()
    SOCCER = auto()

    def is_racquet_sport(self) -> bool:
        return self in {self.TENNIS, self.PING_PONG}
                # error: Non-overlapping container check (
                #           element type: "Game",
                #           container item type: "auto"
                #           )
                #           [comparison-overlap]

Expected Behavior

No errors should be issued.

Actual Behavior

A comparison-overlap error is issued on the return statement:

the_code_above.py:13: error: Non-overlapping container check (element type: "Game", container item type: "auto")
Found 1 error in 1 file (checked 1 source file)

Additional notes

Changing the element references from e.g. self.TENNIS to Game.TENNIS results in the expected behaviour.

Your Environment

  • Mypy version used: 0.931
  • Mypy command-line flags: --strict
  • Mypy configuration options from mypy.ini (and other config files): none
  • Python version used: 3.8.12
  • Operating system and version: macOS 10.14, homebrew 3.3.12, pyenv 2.2.3
@finite-state-machine finite-state-machine added the bug mypy got something wrong label Jan 31, 2022
@AlexWaygood
Copy link
Member

Note that the docs for the enum module explicitly recommend that you do not access other members via self in this way.

@MestreLion
Copy link
Contributor

Note that the docs for the enum module explicitly recommend that you do not access other members via self in this way.

It seems that while this was the case in Python 3.10, since Python 3.11 there is no such recommendation anymore, and accessing members via other instances (including self) is not only no longer deprecated but officially supported. The only recommendation is to avoid naming clashes between members and methods.

@MestreLion
Copy link
Contributor

MestreLion commented Aug 3, 2023

This bug also happens with literal values instead of auto():

import enum


class Planet(enum.Enum):
    EARTH   = 1
    MARS    = 2
    JUPITER = 3
    SATURN  = 4

    @property
    def is_solid(self) -> bool:
        return self in (self.EARTH, self.MARS)

    @property
    def is_home(self) -> bool:
        return self is self.EARTH


home = Planet.EARTH
print(home)
print(home.MARS)
print(home.is_home)
print(home.is_solid)
$ python3.8 teste.py 
Planet.EARTH
Planet.MARS
True
True
$ mypy teste.py 
teste.py:12: error: Non-overlapping container check (element type: "Planet", container item type: "int")  [comparison-overlap]
teste.py:16: error: Non-overlapping identity check (left operand type: "Planet", right operand type: "Literal[1]")  [comparison-overlap]
Found 2 errors in 1 file (checked 1 source file)
$ mypy --version 
mypy 1.4.1 (compiled: yes)

Btw, same errors if running as mypy --python-version 3.11 teste.py

@MestreLion
Copy link
Contributor

I believe this is a duplicate of #10910

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong priority-2-low topic-enum
Projects
None yet
Development

No branches or pull requests

4 participants