Assert statements in Enum subclass definitions case errors when assertion rewriting is enabled

[finite-state-machine]

While running pytest with the following code:

from enum import Enum

STEP = 100

class SomeEnum(Enum):

    FIRST = 100
    SECOND = FIRST + STEP
    THIRD = SECOND + STEP

    assert THIRD == 300

...assertion rewriting causes an error because of an interaction with Enum:

================================ test session starts ================================
platform darwin -- Python 3.8.12, pytest-6.2.5, py-1.9.0, pluggy-0.13.1
rootdir: /private/tmp/pytest-enum-assert-bug
plugins: profiling-1.7.0, order-1.0.1, cov-3.0.0
collected 0 items / 1 error

====================================== ERRORS =======================================
______________________________ ERROR collecting bug.py ______________________________
bug.py:5: in <module>
    class SomeEnum(Enum):
bug.py:11: in SomeEnum
    assert THIRD == 300
/Users/dsuffling/.pyenv/versions/3.8.12/lib/python3.8/enum.py:112: in __setitem__
    raise TypeError('Attempted to reuse key: %r' % key)
E   TypeError: Attempted to reuse key: '@py_assert1'
============================== short test summary info ==============================
ERROR bug.py - TypeError: Attempted to reuse key: '@py_assert1'
!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!
================================= 1 error in 0.28s ==================================

This error does not occur with --assert=plain:

================================ test session starts ================================
platform darwin -- Python 3.8.12, pytest-6.2.5, py-1.9.0, pluggy-0.13.1
rootdir: /private/tmp/pytest-enum-assert-bug
plugins: profiling-1.7.0, order-1.0.1, cov-3.0.0
collected 0 items

=============================== no tests ran in 0.02s ===============================

In fact, the issue can be reproduced by:

from enum import Enum

class SomeEnum(Enum):
    assert True

Environment:

pytest version: 6.2.5
environment: macOS 10.14, homebrew 3.3.12, pyenv 2.2.3, CPython 3.8.12
pip list (new virtualenv; nothing but pytest installed):

Package    Version
---------- -------
attrs      21.4.0
iniconfig  1.1.1
packaging  21.3
pip        21.1.1
pluggy     1.0.0
py         1.11.0
pyparsing  3.0.7
pytest     6.2.5
setuptools 56.0.0
toml       0.10.2

[RonnyPfannschmidt]

@finite-state-machine adding the magic value PYTEST_DONT_REWRITE to the docstring of the module can help as a temporary workaround

[RonnyPfannschmidt]

@nicoddemus i believe we may have to opt out of assertion rewriting in class bodies and/or turn the assert statement into a traceback hiding function

this may also affect other classes that use own namespace types

[nicoddemus]

i believe we may have to opt out of assertion rewriting in class bodies

@RonnyPfannschmidt why do you say that? At first glance it seems it should be possible to fix the problem (but I have not looked into it).

[RonnyPfannschmidt]

@nicoddemus the execution namespace in a class may have special meaning, so we ought not to affect it in such cases

[yuvalshi0]

Just from quick analysis of this code,
The issue come from rewrite [temporary variables clear].(https://github.com/yuvalshi0/pytest/blob/8b211983ff11be5238f90bfd0b3523f03fea09ae/_pytest/assertion/rewrite.py#L463)

From reading this part I assume what pytest actually runs is:

class SomeEnum(Enum):
    @py_assert0 = True
    ...  # rewrite magic
    @py_assert = None

Causing a double Enum key statement inside the Enum class body.
I personally think there is no a straightforward fix for this issue, even if you detect the assert statement is inside a class body, you don't have any way to know that it does not allow duplicate members, such as this case.

[alexchen-sys]

PR up: #14867 — class-body asserts are no longer rewritten (method asserts keep full rewriting), with unit + e2e tests reproducing the exact Enum case from this issue.

[istoolsfox]

I'd like to help get this one closed, so I spent some time in AssertionRewriter.run() on current main. Before writing any code I want to check that the direction is wanted, especially given that #14867 and #14961 both got closed recently.

Still reproducible on main (pytest 9.2.0.dev362+g51e9a9f14, CPython 3.12.10), with the minimal class SomeEnum(Enum): assert True form from the issue:

TypeError: '@py_assert1' already defined as True

Root cause. run() (src/_pytest/assertion/rewrite.py:665) walks the module AST with a flat worklist and rewrites every ast.Assert found in any statement list — it doesn't distinguish a module body from a class body or a function body. For assert THIRD == 300, visit_Assert emits into the enclosing namespace:

@py_assert1 = THIRD == 300
if not @py_assert1: ...
@py_assert1 = None   # "Clear temporary variables", rewrite.py:927

An Enum class body executes through _EnumDict.__setitem__, which treats every non-underscore key as a member definition and rejects the second store of the same name. Note the failure is the duplicate store, not the temp name: dropping only the = None cleanup would instead make @py_assert1 a bogus enum member, which is arguably worse. The rewrite fundamentally needs stores, and any store is unsafe in a class namespace whose metaclass forbids reusing keys — something the rewriter cannot know statically. That matches Ronny's 2022 point that the class execution namespace may have special meaning.

About the two recent attempts, in case it saves anyone a review cycle (I applied both patches locally against current main to check):

• Do not rewrite asserts in class bodies (#9582) #14867 gates on self.scope[-1], but self.scope was removed from the rewriter in the walrus double-evaluation refactor (aeade5e, May 2026). The patch applies cleanly but fails at runtime with AttributeError: 'AssertionRewriter' object has no attribute 'scope' on the first rewritten assert — it was written against pre-refactor code.

• fix(rewrite): skip assertion rewriting in class bodies #14961 applies and works for an assert directly in ClassDef.body, but only gates that one field, so an assert inside a compound statement in the class body still gets rewritten and still crashes:

  class SomeEnum(Enum):
      A = 1
      B = 2
      if B > A:
          assert A == 1   # still rewritten -> same TypeError

Proposal. Make the run() traversal scope-aware: carry a scope tag (module / function / class) alongside each node in the worklist. A ClassDef puts its children in class scope, FunctionDef/AsyncFunctionDef in function scope, everything else inherits the parent's tag; an Assert encountered in class scope is left untouched. This handles the compound-statement and nested-class cases naturally, while asserts in methods (including methods of enum classes) keep full rewriting, matching the direction sketched earlier in this thread. The cost is that class-body asserts lose their failure explanation — they degrade to plain asserts, which is rare enough in practice that it seems acceptable, and the alternative (rewriting class-body asserts without temp stores) would mean rebuilding the explanation machinery from scratch.

If this direction sounds right, I'm happy to put up a PR with tests (unit test that class-body asserts at any nesting depth stay unrewritten while method asserts are still rewritten, plus an e2e test with the Enum case from this issue) and a changelog entry. And if you'd rather wontfix class-body asserts entirely, that's fine too — just let me know either way.