[IhorNehrutsa]

Docs in:
docs/library/enum.rst: Add Enum class. #16842
Usage example:

from enum import Enum

class Color(Enum):
    RED = 'red'
    GREEN = 'green'

print(Color.RED)          # Color.RED
print(Color.RED.name)     # RED
print(Color.RED.value)    # red
print(Color.__members__)  # {<Color.GREEN: 'green'>: 'green', <Color.RED: 'red'>: 'red'}
print(list(Color))        # [<Color.RED: 'red'>, <Color.GREEN: 'green'>]
print(Color["RED"])       # Color.RED
print(Color("red"))       # Color.RED

EDITED:
Inspired by @shariltumin Dot class from the Way to use dot notation to refer to states in a state machine #15694
and @njourdane enum() func from the Request for package: micropython-enum #269

EDITED October 2026:
See README.md, `CPy/CPy.py'
@MrCodeGameandAnime Thank you very much. I catch idea of immediate member availability after class definition from the DD’s enum implementation.

Standard Behavior (Compatible)

• ✅ Member access: Color.RED, .name, .value
• ✅ Member iteration: for item in Color
• ✅ IntEnum and StrEnum types with strict value checking
• ✅ Immutability: members cannot be modified after creation
• ✅ Functional API: Enum('Name', {'KEY': value, ...})

Non-Standard Behavior

Key differences from CPython:

• Name-based lookup via call: Color("RED") works for both name and value lookup (CPython standard call only supports value lookup).
• Value equality: Color.RED == 1 is True (only true for IntEnum in CPython).
• Custom methods: .dump() does not exist in stdlib Enum.
• Callable members: Color.RED() returns the value (not supported in CPython).
• Instance __len__: len(Color) works; CPython enums are not containers.
• Serialization: dump() for eval-based reconstruction is MicroPython-specific.

Comparing the implementations

Feature	CPython	enum.py	enum_mini.py
Enum types	Enum, IntEnum, StrEnum	Enum, IntEnum, StrEnum	Enum
Lookup by name	Color["RED"]	Color("RED") or Color["RED"]	Color("RED")
Lookup by value	Color(1)	Color(1)	Color(1)
Iteration	for item in Color	for item in Color	for item in Color
Iteration in __members__	Yes	Yes	Yes
__members__ mapping	Name to member	Member to raw value	Member to raw value
Functional API	Dict, names string, list/tuple, or iterable	Dict, names string, list/tuple, or iterable	Dictionary only
start for generated integer values	Yes	Yes	No
Strict integer/string member types	IntEnum / StrEnum	IntEnum / StrEnum	Not provided
Length	Not provided	len(Color)	len(Color)
.dump()	No	Yes	No
Plain Enum member equals its raw value	No	Yes	Yes
Member is an instance of its enum class	Yes	No	No
Calling a member, e.g. Color.RED()	Not supported	Returns its raw value	Returns its raw value

Code size report: enum.py
esp32: +2688 +0.148% ESP32_GENERIC[incl +2688(data)]
mimxrt: +2632 +0.668% TEENSY40
rp2: +2612 +0.270% RPI_PICO_W
samd: +2632 +0.947% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Code size report: enum_mini.py
esp32: +1568 +0.087% ESP32_GENERIC[incl +1568(data)]
mimxrt: +1544 +0.392% TEENSY40
rp2: +1532 +0.158% RPI_PICO_W
samd: +1548 +0.557% ADAFRUIT_ITSYBITSY_M4_EXPRESS

[IhorNehrutsa]

Usage example::

from enum import Enum

class State(Enum):
  Stop = 10
  Run = 20
  Ready = 30

state = State()
print("state:", State)

current_state = state.Stop
print("current_state:", current_state, current_state.name)
if current_state == state.Stop:
  print(" Stop state")
if current_state != state.Ready:
  print(" Not a Ready state")
  print(" Run!")
  current_state = state.Run
print("current_state:", current_state, current_state.name)
# some process
i = -1
while current_state != state.Ready:
  i += 1
  try:
      if state(i) == state.Ready:
          current_state = state.Ready
  except:
      pass
  print(".", end="")
print()
print("current_state:", current_state, state(current_state))
print("Done!")

Output is::

state: <enum 'State'>
current_state: State.Stop Stop
 Stop state
 Not a Ready state
 Run!
current_state: State.Run Run
...............................
current_state: State.Ready State.Ready
Done!

[dpgeorge]

Thanks for the contribution, this looks pretty good!

Did you implement this from scratch, or copy parts from CPython's implementation? I'm just wondering about licensing and copyright.

Can you please add the test to the CI, in tools/ci.sh inside the function ci_package_tests_run.

[IhorNehrutsa]

Did you implement this from scratch, or copy parts from CPython's implementation?

I just saw CPython Enum. It looks like incredible magic. :-)

[dpgeorge]

I just saw CPython Enum. It looks like incredible magic. :-)

That doesn't really answer the question. Did you copy this implementation from CPython?

Also, please make sure the CI all passes, there's currently a failure.

[IhorNehrutsa]

| Did you implement this from scratch, or copy parts from CPython's implementation?

No, I didn't use CPython implementation.

It was inspired by @shariltumin Dot class from the Way to use dot notation to refer to states in a state machine #15694
and @njourdane enum() func from the Request for package: micropython-enum #269

[IhorNehrutsa]

Should I squash commits?

[dpgeorge]

I tried to run this test under CPython 3.12.2 but it doesn't work, for many reasons. And it should run under CPython so we can test that the implementation of MicroPython's enum matches the CPython enum.

For example, enum does not exist in the enum CPython module. Which version of CPython were you testing against?

[IhorNehrutsa]

Version 1.4 matches CPython as I could manage.

[dpgeorge]

CPython doesn't have __len__ on an enum.

[IhorNehrutsa]

from enum import Enum

class Color(Enum):
    RED = 1
    GREEN = 2

print(dir(Color))

['GREEN', 'RED', '__class__', '__contains__', '__doc__', '__getitem__', '__init_subclass__', '__iter__', 

'__len__', 

'__members__', '__module__', '__name__', '__qualname__']

[jonnor]

There is a quite comprehensive set of unit-tests for enum available in CPython: https://github.com/python/cpython/blob/main/Lib/test/test_enum.py
With some exceptions like the tests using inspect, threading, pickle it seems possible to port most of them to MicroPython. That would give a very high degree of confidence that the implementation is conformant. And in the cases that one chooses to not be conformant, that can be documented with skipped tests.

[IhorNehrutsa]

I have successfully completed the task that requires the Enum class.
I don't plan to support this PR in the future.
You are welcome to continue working with this PR as you wish.
Thanks everyone.

[mchobby]

@dpgeorge
This PR looks stuck in time. I didn't find enum.py in micropython-lib/python-stdlib/enum.py .
Getting Enum for MicroPython would be really useful .

Need some help on this PR ? Were could I start ?

Dominique

[Josverl]

Need some help on this PR ? Were could I start ?

That would be much appreciated.
I would suggest that making it match Cpython more and changing/adding tests to prove that would be the next step

[IhorNehrutsa]

@mchobby @Josverl You may pull down this PR and try to use enum.py. Please write reviews about usage here

[Josverl]

@IhorNehrutsa, may I ask why you closed the documentation PR?

[IhorNehrutsa]

@IhorNehrutsa, may I ask why you closed the documentation PR?

This has been going on for so long that I forgot. :(

[mchobby]

I'm a bit skeptical about the last @IhorNehrutsa action.
As I understand, the initial PR enum.py behavior was too far from CPython implementation.
I was interested to help in reducing the gap between CPython & MicroPython implementation.
That was looking as a "Good-First-Issue" to me (and for me).

On the meanwhile, @IhorNehrutsa pushed an AI rework of the code and "here is it for you to test".
As last arrival in this PR (and micropython-lib), I'm not in great position to evaluate the appropriateness of that rework.
@Josverl could you have a quick review on this for guidance?

Nevertheless, I do not want to be retrograde but being the "human behind the IA for checking the IA work" is not really what I was expecting.
Cheers

[Josverl]

@mchobby,
I agree with the earlier comments that it isn’t the reviewer’s job to try to interpret or “fix up” clearly AI‑generated submissions. If the submitter isn’t putting in at least the same level of effort as the reviewers, the process becomes unbalanced and unsustainable.
That does not mean that AI is not to be used as a tool to create code, but it does mean that there needs to be more that just that.

@IhorNehrutsa , I’m also genuinely confused by the pattern of behavior around these PRs: starting work, abandoning it, then suddenly re‑engaging with AI‑generated updates, along with the closing, and re‑opening of related PRs. It makes it difficult to understand the actual intent, the direction of the contribution, or whether you are committed to following through.
to be clear - I do appreciate your efforts, and I realize that sometimes the wait for a PR to get merged (or even rejected) can exceed ones attention span. but in order for us to work as a community I prefer to have some level confidence.

There is clear interest in having an Enum class available in MicroPython. But implementing one properly is non‑trivial — it touches (the lack of) metaclasses, memory constraints, and the broader philosophy of keeping the core minimal.

At the same time, it’s important that MicroPython stays close to CPython where feasible, while still respecting MicroPython’s own design principles and constraints. Achieving that balance requires careful design and discussion, not a surface‑level or (mostly) AI‑generated port.

I have not had the time to look at the most recent tests and code - but I do plan to do that in the next few days.

[IhorNehrutsa]

Okay. No one minds if I copy the previous version of enum.py to enum_0.py, the latest to enum_1.py, then we'll choose the best implementation options for enum.py from them.

[IhorNehrutsa]

There is a quite comprehensive set of unit-tests for enum available in CPython: https://github.com/python/cpython/blob/main/Lib/test/test_enum.py With some exceptions like the tests using inspect, threading, pickle it seems possible to port most of them to MicroPython. That would give a very high degree of confidence that the implementation is conformant. And in the cases that one chooses to not be conformant, that can be documented with skipped tests.

Can someone write a MicroPython version of the CPython tests https://github.com/python/cpython/blob/main/Lib/test/test_enum.py ?

[MrCodeGameandAnime]

I have a concrete StrEnum use case from an application sharing model definitions between CPython and MicroPython.

Two behaviors matter for its validators:

• Members expose .name and .value immediately after class definition.
• isinstance(Mode.FAST, Mode) succeeds.

I compared CPython 3.12.14, my application’s existing StrEnum implementation, and this PR at f1a9f168, running both MicroPython implementations on the same native Windows build of MicroPython 1.29.0.

Explicit initialization resolves several differences in the PR, but its members still aren’t instances of their declared enum class.

The application implementation achieves both behaviors, although it uses a process-wide __build_class__ wrapper and has other compatibility limitations. I haven’t measured its overhead or established that this mechanism would be appropriate upstream.

Are immediate member availability and declared-enum instance identity intended goals for the supported subset? I have a small synthetic comparison runner and recorded results that could help investigate those requirements.

[IhorNehrutsa]

@MrCodeGameandAnime
I am not sure that I fully understand your question.

from enum import Enum

class Color(Enum):
    RED = 'red'
    GREEN = 'green'

print(Color)
print(type(Color))
print(Color.RED)
print(type(Color.RED))
print(isinstance(Color.RED, Color))

try:
    import machine
    
    print()
    # Initialize
    Color()

    print(Color)
    print(type(Color))
    print(Color.RED)
    print(type(Color.RED))
    print(isinstance(Color.RED, Color))
except:
    pass

Python 3.12.2

<enum 'Color'>
<class 'enum.EnumType'>
Color.RED
<enum 'Color'>
True

MicroPython v1.29

<class 'Color'>
<class 'type'>
red
<class 'str'>
False

<class 'Color'>
<class 'type'>
Color.RED
<class 'Color.RED'>
False

Are immediate member availability and declared-enum instance identity possible?
The short answer is no.

• Immediate member availability after class definition requires a metaclass (which is not implemented in MicroPython yet).
• I haven't investigated whether it is possible to access isinstance and type.

You may look at #1061

[MrCodeGameandAnime]

@IhorNehrutsa

Thanks for the explanation and the pointer to #1061. I’ve now tested both approaches alongside the implementation used in my game, Dungeon Drifters.

For the narrower StrEnum case, immediate member availability and declared-enum instance identity are possible on existing MicroPython without adding metaclass support to the interpreter. DD’s implementation provides this behavior on the native Windows port of MicroPython 1.29.0:

from enum import StrEnum

class Mode(StrEnum):
    FAST = "fast"
    SLOW = "slow"

assert Mode.FAST.name == "FAST"
assert Mode.FAST.value == "fast"
assert isinstance(Mode.FAST, Mode)
assert isinstance(Mode.FAST, str)
assert Mode("fast") is Mode.FAST
assert Mode(Mode.FAST) is Mode.FAST

The mechanism creates actual instances of the declared string subclass and finalizes members through a process-wide __build_class__ hook. That hook is a significant integration tradeoff; its composition and performance costs still need evaluation. DD also implements a limited subset with differences from CPython, rather than full enum compatibility.

The original implementation and application contract tests are public:

• [DD’s enum implementation](https://github.com/MrCodeGameandAnime/Dungeon-Drifters/blob/master/root/portability/micropython/enum.py)
• [Enum contract tests](https://github.com/MrCodeGameandAnime/Dungeon-Drifters/blob/master/root/tests/test_enum_contract.py)
• [Portability tests](https://github.com/MrCodeGameandAnime/Dungeon-Drifters/blob/master/root/tests/test_portable_enum.py)

I extracted synthetic cases from those requirements into a reproducible comparison at commit dff4986. It runs the same 61 observations against native CPython, DD’s unchanged overlay, and pinned #980 code. Explicit initialization resolves several #980 differences, but members still fail isinstance(member, DeclaredEnum) afterward. [Full results](https://github.com/MrCodeGameandAnime/enum_980/blob/dff498630e5908236a801d84f5a07b88979a351a/docs/comparison.md).

I also built #1061’s proposed companion core with all four metaclass options enabled. Immediate member access and declared-enum identity work there. The remaining differences relevant to DD include isinstance(member, str) returning false, existing-member lookup raising ValueError, and hashes differing from the underlying strings. [Separate results and exact revisions](https://github.com/MrCodeGameandAnime/enum_980/blob/dff498630e5908236a801d84f5a07b88979a351a/docs/pr1061-comparison.md).

[GitHub CI reproduced both comparisons](https://github.com/MrCodeGameandAnime/enum_980/actions/runs/38917607382), built both interpreters, and passed all 20 harness tests without skips.

Would immediately usable, correctly typed StrEnum members be an intended compatibility goal? If so, could DD’s member-construction approach inform the implementation while we work out an acceptable class-finalization mechanism?

[IhorNehrutsa]

@MrCodeGameandAnime Thank you very much. I wil develop the immediate member availability after class definition.

[MrCodeGameandAnime]

@IhorNehrutsa if you don't mind, I’d like to contribute the implementation. Are you be open to me preparing a focused patch based on DD’s approach for your branch? I'd be grateful for the opportunity to build upon your existing work. Having even narrow developmental participation in the Python ecosystem means the world to me, especially MicroPython.

[IhorNehrutsa]

Version 1.5.0 support the the immediate Enum member availability after class definition.

@MrCodeGameandAnime
Thank you for your willingness to contribute! You are very welcome to collaborate on this project, and I’d be happy to have your help.

I would especially appreciate it if you could review the code, test the implementation, and check the README.md for accuracy, clarity, and completeness. Your feedback and suggestions would be very valuable in improving the quality of the code and documentation.

[MrCodeGameandAnime]

@IhorNehrutsa

I’ve prepared a focused contribution package based directly on c3b5aae, building on your class-finalization hook and DD’s typed-member construction approach.

The patch gives StrEnum members their genuine declared class identity while keeping direct functional creation, canonical lookup, declared methods, class iteration, and ordinary string indexing/slicing.

It also addresses full/mini builder hook coexistence, fresh imports retaining older aliases, and mini’s missing length operation. Generic Enum and IntEnum implementations remain unchanged. Regression coverage stays in the existing two test files, and the README distinguishes the container and typed class profiles.

I ran both package test files directly in separate processes on unmodified stock MicroPython 1.29.0 on Windows and Unix, normally and with -O2. Each configuration reports 21 tests OK and 8 tests OK. I repeated that validation after transplanting the changes onto the clean branch.

The README documents the remaining stock-runtime limits, including class length/subscription, class mutation guards, representation differences, and string-subclass dictionary/JSON keys.

Separately, the pinned manifest still declares version 1.4.0, while the commit describes 1.5.0. I left that untouched for your attention.

[MrCodeGameandAnime]

@dpgeorge @agatti @Josverl
I’m tagging you because this concerns contribution provenance and the subsequent development of PR #980. I’m not asking anyone to take sides. I’m documenting the public timeline so the sequence of contributions, comments, and commits is clear, and I’m ending my involvement with this work.

Public timeline of my contribution to micropython-lib PR #980

The sequence of events is important, and I want there to be a clear record of what was contributed, when it was contributed, and what happened afterward.

For reference, this is the repository where my analysis, testing, reproductions, and solution work for this issue were developed and documented: https://github.com/MrCodeGameandAnime/enum_980

All times below are UTC.

October 16, 2026, 14:51:58 UTC

I posted a detailed technical analysis explaining that immediate enum-member availability and genuine declared StrEnum instance identity were possible on existing stock MicroPython without adding metaclass support to the interpreter.

I specifically demonstrated the approach already used by Dungeon Drifters, explained that it creates actual instances of the declared string subclass, described the process-wide __build_class__ finalization mechanism, linked the implementation and tests, and provided reproducible comparison results against both PR #980 and the proposed metaclass work in #1061.

#980 (comment)

The relevant question I asked was whether DD's member-construction approach could inform the implementation if immediately usable, correctly typed StrEnum members were an intended compatibility goal.

October 17, 2026, 06:53:27 UTC

Approximately 16 hours later, Ihor replied:

"Thank you very much. I will develop the immediate member availability after class definition."

#980 (comment)

This response directly followed the technical work and implementation approach I had published the previous day.

October 17, 2026, 12:40:55 UTC

I then explicitly asked to contribute the implementation myself:

"If you don't mind, I’d like to contribute the implementation. Are you open to me preparing a focused patch based on DD’s approach for your branch?"

I also explained that having even narrow developmental participation in the Python ecosystem, especially MicroPython, meant a great deal to me.

#980 (comment)

October 18, 2026, 14:18:50 UTC

Ihor responded that version 1.5.0 now supported immediate enum-member availability.

He then told me:

"You are very welcome to collaborate on this project, and I’d be happy to have your help."

But the work he specifically asked me to perform was:

"review the code, test the implementation, and check the README.md for accuracy, clarity, and completeness."

#980 (comment)

October 18, 2026, 14:46:29 UTC

Only about 28 minutes after that comment, commit c3b5aae was recorded on Ihor's branch:

python-stdlib\enum: Bump to version="1.5.0".

The commit description states:

"The builder hook allows using an Enum without lazy initialization."

c3b5aae

So the first sequence is straightforward:

I publicly demonstrated the approach and implementation mechanism. Ihor said he would develop it. I explicitly asked to contribute to that implementation. The implementation then appeared under his commit, after which I was invited to review and test it.

October 20, 2026, 01:06:54 UTC

I did exactly the review, testing, and engineering work I had been invited to do.

I posted that I had prepared a focused contribution based directly on c3b5aae.

The contribution included:

• genuine declared-class identity for StrEnum members
• preservation of direct functional StrEnum(...) creation
• canonical lookup behavior
• declared methods
• class iteration
• ordinary string indexing and slicing
• full/mini builder-hook coexistence
• preservation of older aliases across fresh imports
• the missing mini enum length operation
• expanded regression coverage
• README/documentation updates
• validation on unmodified MicroPython 1.29.0 on Windows and Unix
• normal and -O2 execution
• 21 full enum tests and 8 mini enum tests

#980 (comment)

October 20, 2026, 02:02:40 UTC

Less than an hour later, I opened an actual pull request against Ihor's enum branch:

PR #1: python-stdlib/enum: Improve StrEnum behavior and tests

IhorNehrutsa#1

The PR was based specifically on:

c3b5aaeb61c33ee13c70a6d3dfcd95a8b185e297

It contained one commit modifying 8 files with 542 additions and 88 deletions.

The PR description explicitly documented the implementation, tests, tradeoffs, supported behavior, stock-MicroPython limitations, and the cooperative __build_class__ work.

October 20, 2026, 20:30:13 UTC

Approximately 18½ hours after my PR was opened, Ihor pushed:

3fac58bb330edfc6754cfa761d897e530091a675

with the title:

python-stdlib\enum: Bump to version="1.5.1".

3fac58b

This was not merely a version-number change.

Among other changes, it altered enum-member construction so the generated member inherited from both the raw value type and the enum class:

(type(v), cls)

It also changed functional construction, member lookup, extension behavior, class initialization, the builder hook, and the way typed enum members were represented and initialized.

These were the same core implementation areas addressed by my submitted contribution.

October 20, 2026, 20:31:57 UTC

Just 104 seconds later, Ihor pushed:

1310b91d758edefb8de789d4abb5637a5967542b

with the title:

python-stdlib\enum_mini: Bump to version="1.5.1".

1310b91

That commit substantially reworked enum_mini.py, including:

• enum-member inheritance from the declared enum class
• functional enum construction
• lookup behavior
• subclass-extension behavior
• __len__
• initialization
• the __build_class__ mechanism

Again, these overlap directly with areas I had just addressed in my submitted PR.

Result

My PR was originally created against c3b5aae.

Ihor's subsequent 1.5.1 commits advanced that same base branch and changed the same implementation files, leaving my contribution conflicted.

The overlap includes:

• python-stdlib/enum/CPy/CPy.py
• python-stdlib/enum/enum.py
• python-stdlib/enum/enum_check.py
• python-stdlib/enum/enum_mini.py
• python-stdlib/enum/enum_usage.py
• python-stdlib/enum/test_enum.py
• python-stdlib/enum/test_enum_mini.py

My PR remains open, unmerged, and currently non-mergeable because the base branch changed underneath it.

Attribution

For completeness, the current PR #980 description has since been edited to include:

"@MrCodeGameandAnime Thank you very much. I catch the idea of immediate member availability after class definition from the DD’s enum implementation"

So the public PR itself now explicitly acknowledges that the immediate-member-availability idea came from Dungeon Drifters.

That acknowledgement is important because it independently establishes the provenance of that part of the work.

Why I am ending my involvement

This happened twice in the same short sequence.

First, I publicly demonstrated a technical solution. Ihor said he would develop it. I explicitly asked to contribute the implementation myself. The implementation then appeared under his authorship, and I was invited to review and test it instead.

I accepted that invitation in good faith.

I then performed substantial engineering, testing, documentation, and review work and submitted a focused pull request.

Within approximately 18½ hours of that PR being opened, substantial overlapping implementation changes were again pushed directly into Ihor's branch under his own commits, changing the same core areas and displacing my contribution.

Those are not assumptions about anyone's intent. They are the publicly recorded sequence of events, commits, timestamps, comments, and pull requests.

Anyone can review the links above and draw their own conclusions.

For my part, I am no longer willing to contribute implementation work, testing, review, debugging, research, or technical solutions to this project under these circumstances, despite my extensive use of MicroPython in Dungeon Drifters and work informed by https://github.com/orgs/micropython/discussions/18291.

My sole goal was to help move Enum forward so Dungeon Drifters could eventually consume a maintained upstream implementation instead of relying on a local compatibility shim. The maintainers asked for a concrete use case, and I provided one through a real, active game, along with implementation work, testing, and reproducible results. I thought working with @IhorNehrutsa and demonstrating a real downstream need would show this work is valuable and that the community cares. I delivered what was asked for. However, I will not be taken advantage of repeatedly.

PR #980 has been stuck for months and has been open since 2025. A team could have gotten this done. Now it is back to one. This situation is exactly why someone like me, who absolutely loves software, rarely works with other people. I gave faith, trust, and respect to this collaboration. In return, I received a pat on the back and an attaboy while the work I contributed was absorbed elsewhere.

Good day,
MrCodeGameAndAnime

[Josverl]

@MrCodeGameandAnime

I’m tagging you because this concerns contribution provenance and the subsequent development of PR #980.’

While I'm also just a contributor, I want to thank you for your willingness to help improve MicroPython.

I'm sorry to read that this experience has led you to step away from contributing. If that is your decision, I think the community is losing a enthusiastic contributor.

One thing I would like to clarify is that your PR was opened against someone's personal fork rather than the main micropython/micropython-lib repository. Because of that, I would encourage you not to judge the broader MicroPython community solely on this particular experience. Of course, that's entirely your choice, and I can understand why the situation has been frustrating.

In my own experience, collaboration on pull requests can be difficult. It is not just about merging Git branches into someone else's fork; it is also about combining different ideas, approaches, and expectations. Questions of authorship and recognition can sometimes become part of that process as well.

In some situations, it works better to open a separate PR of your own that incorporates contributions from multiple people and clearly credits everyone involved. Perhaps that might be worth considering in the future, whether for this project or another one.

I also noticed that your "PR to the PR" has since been merged. That said, I was surprised to see that you do not appear as the author of the resulting commit, as I would have expected your contribution to be reflected there.

In any case, thank you again for your efforts and for taking the time to contribute. Even when things do not go smoothly, contributions like yours help move projects forward.

[projectgus]

Hi all,

I'm coming in late to this discussion and it's taken me a little while to read all the comments and try to get up to speed. I'm not confident I fully understand all the issues, so please tell me if I'm mistaking anything

I want to start by acknowledging that both @IhorNehrutsa and @MrCodeGameandAnime have done a bunch of work here, and thank you both for putting in the time to work on upstream contributions. I particularly appreciate whenever someone builds something for their own project and looks to generalise it into MicroPython, it's often a good indicator of features that will be useful to others.

I also acknowledge that feedback from maintainers is often hard or slow to get, and I'm sorry about that.

My understanding of @MrCodeGameandAnime's most recent reply is that the major issue here is attribution. I see the Dungeon Drifter's code is under a proprietary license so we can't adapt it directly, but if I understand correctly this PR's contents is intended to be MIT licensed as a contribution to micropython-lib, via Ihor's fork? If so, then suggest this PR adds attribution by naming all contributors via copyright statements in the relevant source files (we don't do a great job being consistent about this in micropython-lib, but a good example to follow is the cbor2 library.)

I also wanted to echo Jos, that I hope one bad experience doesn't put anyone off contributing to MicroPython - but understand if it has, @MrCodeGameandAnime.

On the "big picture" view of enum support, this PR, and the alternative #1061: from what I can see both of these PRs need significant work before being ready to merge into micropython-lib. However, this approach seems very viable as it doesn't depend on metaclass support landing first (and it still seems to still do well on feature completeness, code size, usefulness, etc.)

One major outstanding request I see in the comments is to look at porting CPython's enum tests to MicroPython. It looks like @IhorNehrutsa was looking for help with this earlier in the year but nobody has stepped up. Am I missing anything there?

@IhorNehrutsa are you still interested in working on this PR? If so then I can provide more detailed review comments on some other parts of the code/docs.

[andrewleech]

One major outstanding request I see in the comments is to look at porting CPython's enum tests to MicroPython. It looks like @IhorNehrutsa was looking for help with this earlier in the year but nobody has stepped up. Am I missing anything there?

My PR in #1061 has tests based on the cpython test suite so should be (hopefully) directly usable here. It's true my PR is intended to be built on top of a minimal metaclass impl in micropython itself in the linked PR, I've put efforts into making both the C and py code as small as possible for the features added - but it still adds up to a fair bit of code!

[IhorNehrutsa]

@projectgus Yes, I am still working on PR. Give me a time for v1.5.2

The PR from @MrCodeGameandAnime was my first PR, and it turned out to be unsuccessful—both in terms of technical aspects and communication. :(

@andrewleech Could you create a PR to the https://github.com/IhorNehrutsa/micropython-lib/tree/enum that includes the common CPython/MicroPython test file from #1061?
I’d like to take another look at how PR works, and perhaps you could advise on the "proper" way to handle thus PRs.

[MrCodeGameandAnime]

@Josverl @projectgus

I appreciate you both taking the time to review what occurred and understand why I decided to step away. Initially, I was certain my involvement was over. However, after reading your responses and seeing how much work remains, I'm willing to reconsider.

My goal was always to help get Enum into MicroPython, and that hasn't changed.

I also want to expand on Dungeon Drifters as a downstream use case, particularly since @projectgus mentioned the value of bringing solutions developed for real projects into MicroPython.

Dungeon Drifters has an extensive MicroPython runtime qualification probe that I've been developing and documenting alongside the game. This goes well beyond isolated unit tests, exercising actual gameplay systems, including combat, progression, recruitment, dungeon traversal, extraction, persistence-related state transitions, and memory-constrained execution.

The October 29 qualification used a pinned MicroPython 1.29.0 Windows build, alongside CPython semantic-parity checks. It passed three consecutive full-loop runs at a 608 KB heap boundary, while the expected memory-limit classification was reproduced three times at 576 KB.

The implementation, qualification history, memory-pressure findings, and limitations are documented here:

https://github.com/MrCodeGameandAnime/Dungeon-Drifters/blob/master/docs/probe.md

The successful hosted qualification is available here:

https://github.com/MrCodeGameandAnime/Dungeon-Drifters/actions/runs/40914215425

I understand the licensing distinction between Dungeon Drifters' proprietary implementation and contributions to micropython-lib. I'm not suggesting incorporating proprietary code directly. The purpose of sharing this work is to demonstrate an existing downstream application, its compatibility requirements, and a testing environment that may be useful in evaluating upstream implementations.

Before moving forward, I'd like three things established.

First, proper attribution. I recognize that @IhorNehrutsa has put substantial effort into PR #980. That is precisely why I credited his work in my own contribution, which was built upon his existing implementation. I expect that same recognition for my engineering work, including appropriate authorship and attribution when it is incorporated.

Second, a clear collaborative process. I have no intention of creating a competing fork or fragmenting development unnecessarily. I'm willing to continue contributing directly to Ihor's branch, provided we establish that submitted contributions will be reviewed collaboratively rather than superseded by overlapping implementations without discussion, and that authorship will be properly preserved.

Third, a concrete path to completion. We already have substantial implementation work, targeted regression coverage, and the possibility of incorporating CPython-derived tests from #1061, as @andrewleech mentioned.

Looking through the earlier discussion, several requirements have been raised repeatedly. These include improving CPython compatibility, running meaningful tests against both interpreters, documenting intentional deviations from CPython, and ensuring that the implementation satisfies MicroPython's memory and code-size constraints.

There are also practical integration issues remaining. The current PR has passing package, lint, and spelling checks, but the commit-message formatting check is failing, merge conflicts remain, and the PR is still in draft.

I believe the next step should be to establish which behaviors are required for upstream acceptance, identify the remaining compatibility gaps, and build a common test suite that clearly distinguishes supported behavior, intentional deviations, and runtime limitations.

Dungeon Drifters can complement that effort by providing real downstream qualification alongside the broader CPython compatibility tests.

With the existing work and the experience of everyone now involved, I believe we have the resources to get this finished. What we need is an agreed direction and a clear division of responsibilities.

I don't want to revisit the previous dispute indefinitely. The public record is there, and my position remains unchanged. However, I also don't want to see a viable implementation remain unfinished when there's an opportunity for us to work together and complete it.

I'm willing to contribute further engineering, testing, compatibility analysis, documentation, and review to help get Enum across the finish line.

So, what specifically remains before PR #980 can be accepted upstream, and which areas would you like me to take responsibility for?

Thank you,
MrCodeGameAndAnime