Skip to content

Enum with str or int Mixin Breaking Change in Python 3.11 #100458

Description

@anze3db

Bug report

Looks like there was a breaking change with the way str and int mixins work with Enums in Python 3.11:

from enum import Enum


class Foo(str, Enum):
    BAR = "bar"

# Python 3.10
f"{Foo.BAR}"  # > bar

# Python 3.11
f"{Foo.BAR}"  # > Foo.BAR

The same goes for Enum classes with the int mixin.

In my project we were relying on Foo.BAR to return the enum value, so this change broke our code. We fixed it by replacing str Enum mixin with the newly added StrEnum class (thanks for that, it's exactly what we needed!).

I think reverting the breaking change would only introduce another breaking change so that's probably not the way to go. But maybe updating the whatsnew page and call out the change there could help people stumbling into this when doing the upgrade. I've found the existing point about this change in the release notes a little bit confusing and I have already opened a PR to try and clear it up a bit: #100387

I've also written a longer blog post about it here, and there has been some lively discussion in r/python.

Your environment

  • CPython versions tested on: 3.11.0, 3.11.1
  • Operating system and architecture: MacOS, Ubuntu 22.04

Linked PRs

Activity

  1. added
    docsDocumentation in the Doc dir
    3.11only security fixes
    on Dec 23, 2022
  2. JosephSBoyle commented on Dec 25, 2022

    @JosephSBoyle
    Contributor

    @anze3db StrEnum was added in 3.11, does that work as a 'slot in' replacement for your use case?

    docs: https://docs.python.org/3.11/library/enum.html#enum.StrEnum

  3. anze3db commented on Dec 27, 2022

    @anze3db
    ContributorAuthor

    @JosephSBoyle yes, we replaced the str mixin with StrEnum to fix this on our end. If we could let people know about this breaking change in the what's new docs it would save me a lot of head scratching, especially since the current note about this change seems wrong (see my attempt of at least making it a bit more accurate: #100387)

  4. JosephSBoyle commented on Dec 27, 2022

    @JosephSBoyle
    Contributor

    Coincidentally I've also used the mixin approach you describe in professional projects, which suggests that this use is at the very least not uncommon.

    As such it makes sense that the docs also suggest a way to achieve the old behaviour, like you say @anze3db. I've added a small suggestion to your PR; hopefully that will help resolve things for others in the same position!

  5. anze3db commented on Dec 27, 2022

    @anze3db
    ContributorAuthor

    Thank you! The text that you added would have helped me a lot when I was figuring out how to fix this 👍

  6. moved this to Research in enum issueson Mar 30, 2023
  7. added a commit that references this issue on May 1, 2023
  8. added a commit that references this issue on May 1, 2023
  9. added a commit that references this issue on May 1, 2023
  10. added a commit that references this issue on May 1, 2023
  11. 21 remaining items

  12. added a commit that references this issue on Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.11only security fixesdocsDocumentation in the Doc dirtype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions