Skip to content

Support for custom Enum base class #3217

Closed

Description

@ambv

Much of our internal Python code uses a custom Enum class as an optimization above the built-in Enum type. These should be treated the same as built-in enums in terms of the custom enum handling in mypy, but since mypy looks for enum.Enum as the base-class in order to trigger the is_enum behavior, we can't get this to trigger without monkey-patching mypy.

There's a variety of solutions that could help, a couple that could work:

  1. Allow a list of additional Enum base classes to be passed in to mypy or specified in the .ini file, and use those in addition to enum.Enum.
  2. Allow for an annotation on the custom Enum base class that opts that class and any subclasses into the is_enum behavior

We're happy to extend mypy with either of those options (or other suggested ones), but we wanted to get alignment here before starting work.

Activity

  1. gvanrossum commented on Apr 22, 2017

    @gvanrossum
    Member

    Our own custom enums are so crusty that they don't work anyways. :-(

    Maybe a better approach would be to use the EnumMeta class as a flag instead?

  2. ambv commented on Apr 24, 2017

    @ambv
    ContributorAuthor

    Maybe a better approach would be to use the EnumMeta class as a flag instead?

    Could we make this work with a C-based Enum implementation? The thing is, our optimized version is Cython, we wrote it for perf reasons.

  3. gvanrossum commented on Apr 24, 2017

    @gvanrossum
    Member

    I don't understand enough about your problem to propose a solution. Can't you create a stub for it that pretends it derives from enum.Enum?

    Alternatively, if we changed mypy so that instead of checking "is the type exactly enum.Enum (or a few others)" it checked "is this type's metaclass derived from enum.EnumMeta", then could you write a stub?

  4. carljm commented on May 23, 2017

    @carljm
    Member

    A stub with from enum import Enum works just fine for us. Thanks for the suggestion! Slightly embarrassed that none of us thought of that; guess I need to get used to thinking of stubs as a way to lie to mypy ;-)

  5. JukkaL commented on May 23, 2017

    @JukkaL
    Collaborator

    @carljm Can we close this issue now that you have a workaround?

  6. carljm commented on May 24, 2017

    @carljm
    Member

    @JukkaL Yes, fine to close as far as I'm concerned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions