REPL does not show completions for some members of the Enum module

[RafaelWO]

Bug report

Bug description:

While working on improving the Enum documentation, I noticed that all Enum _sunder_ names are not shown in the completion suggestions. Some examples:

• Enum._add_alias_
• Enum._add_value_alias_

$ ./python
Python 3.15.0a0 (heads/main:e18dda96c9, Sep 28 2025, 18:14:51) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
Ctrl click to launch VS Code Native REPL
>>> from enum import Enum
>>> Enum._
Enum._add_member_( Enum._convert_( Enum._find_data_repr_( Enum._find_new_(
Enum._check_for_existing_members_( Enum._create_( Enum._find_data_type_( Enum._get_mixins_(
>>> Enum._add_alias_
<function Enum._add_alias_ at 0x7d38f05fc1d0>

I don't know if this also affects other modules... but I guess it would be great to have a test that checks the completion coverage of the REPL across the stdlib - or is there already a test like this?

Either way, I'm happy to help fix this issue and create a PR if one could guide me to the place where the REPL builds the "completion database" 🙂

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-139398: Make dir(Enum) include public _sunder_ helpers for REPL completions #139418
• gh-139398: Add supported sunder names to Enum __dir__ for REPL completions #139985

[StanFromIreland]

cc @tomasr8

[picnixz]

This could also be because Enum.__dir__ (it's a custom-made function) is missing some entries. I don't think it's a REPL-only issue actually.

[ttw225]

Hi! I'm interested in working on this issue and would like to contribute to the discussion.

I noticed there was a previous PR attempt that was abandoned. I've done some investigation and found that the problem is indeed that several sunder names mentioned in the official documentation are missing from dir() output, which affects REPL autocomplete.

Missing sunder names in dir() output

Level	Name	Type	Description
Instance Level	_name_	Attribute	Name of the member
Instance Level	_value_	Attribute	Value of the member; can be set in __new__
Instance Level	_add_alias_	Method	Adds a new name as an alias to an existing member
Instance Level	_add_value_alias_	Method	Adds a new value as an alias to an existing member
Class Level	_missing_	Method	A lookup function used when a value is not found; may be overridden
Class Level	_generate_next_value_	Method	Used to get an appropriate value for an enum member; may be overridden

Proposed Solution

The fix would involve updating the __dir__ methods in the Enum class:

• Instance __dir__ method: Add _name_, _value_, _add_alias_, _add_value_alias_
• Class __dir__ method: Add _missing_, _generate_next_value_
• I can send a PR with tests in Lib/test/test_enum.py to assert these appear in dir() without changing runtime behavior.

Clarifications

1. Is this the complete list of missing sunder names that should be addressed?
2. I’m not proposing to expose _ignore_ / _order_ because the docs say they are removed during class creation / no longer used, so they shouldn’t be discoverable at runtime.
3. Any concerns about adding these to dir() output?
4. Should _name_ and _value_ be included in dir() in addition to the public .name and .value?
   My understanding is that .name/.value are the public, user-facing attributes, while _name_/_value_ are the internal backing attributes used by Enum. Including _name_/_value_ would improve parity with the “supported sunder names” list and help REPL discoverability, but it also exposes more implementation details in autocomplete. Do we want dir(member) to list both pairs, or keep only the public ones (.name/.value) and exclude the backing fields?

I'd like to confirm these details before implementing to ensure I'm addressing the right scope. Happy to work on this if the approach looks good!

Reference: Python 3.13.7 enum documentation - Supported sunder names

CC: @ethanfurman , @picnixz

Note on tooling: I use LLMs to draft and refine my communication and speed up exploration, but I personally verify the reasoning, review the code and docs, and submit the changes. I’m fully responsible for the final proposal and implementation.

[picnixz]

There is already an open PR. I do not think it is abandoned (?)

[ttw225]

There is already an open PR. I do not think it is abandoned (?)

My bad—poor wording on my side. Not calling it abandoned. I was referring to the latest comment on the PR

Happy to support either way.