I strongly support this feature request. Unsurprisingly, I wholeheartedly agree with desbma's heroic persistence and wholeheartedly disagree with rhettinger's curt dismissal.

> IMO, this adds more complexity than it solves.

Strongly disagree. Because "argparse" fails to support the core "Enum" type out-of-the-box, I now have to either (A) duplicate desbma's boilerplate or (B) duplicate paul.j3's original "EnumType" factory or desbma's revised "EnumType" factory across multiple "argparse"-based CLI interfaces in multiple Python applications having discrete codebases.

Both approaches are noxious, substantially increasing implementation burden and technical debt. While obviously feasible, both approaches violate DRY, invite code desynchronization and concomitant bugs, inhibit maintainability, intelligibility, and documentability, and... the list just crawls on.

DRY violations add complexity. Avoiding DRY violations decreases complexity.

> Argparse already has more options than people can remember.

That's what front-facing documentation, queryable docstrings, and https://docs.python.org/3/library/argparse.html are for. No one remembers even a tenth of the functionality provided by "argparse" or any other reasonably deep module (e.g., "importlib", "subprocess") in the stdlib, yet the stdlib justifiably grows, improves, and strengthens with time.

This is a good thing. API memorability and mnemonics, however, are not. We have machine lookup. Ergo, API memorability and mnemonics are poor metrics by which to gauge feature creep.

I'd hoped it would be intuitively obvious that "Enum" support should be officially added to "argparse". Enums are a core type native to most high-level languages, now including Python. Enum-based argument parsing is a Pythonic solution for string arguments accepting only a well-known set of valid alternatives. The stdlib itself is internally (albeit incrementally) migrating from non-Enums to Enums.

This needs to happen.