Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enum _sunder_ exclusion is overly strict #118650

Closed
chrysn opened this issue May 6, 2024 · 1 comment · Fixed by #118651
Closed

Enum _sunder_ exclusion is overly strict #118650

chrysn opened this issue May 6, 2024 · 1 comment · Fixed by #118651
Labels
type-feature A feature request or enhancement

Comments

@chrysn
Copy link
Contributor

chrysn commented May 6, 2024

Bug report

Bug description:

Enums' exclusive access to _sunder_ members inhibits their use with the IPython/Jupyter pattern of making HTML and other visual reprs available:

from enum import Enum

class MyEnum(Enum):
    A = 1

    def _repr_html_(self):
        return f'<span title="A MyEnum">{self}</abbr>'
# ValueError: _sunder_ names, such as '_repr_html_', are reserved for future Enum use

While having exclusive access to some space is valuable, and prefixing enum's range is not practical (as that prefix would need to be repeated by users constructing the class), carving out some space for widespread functions that are not expected to conflict with Enum's internal use should be possible. I suggest that at least _repr_html_ should be allowed, possibly the whole _repr_ prefix.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Linked PRs

@chrysn chrysn added the type-bug An unexpected behavior, bug, or error label May 6, 2024
chrysn added a commit to chrysn-pull-requests/cpython that referenced this issue May 6, 2024
chrysn added a commit to chrysn-pull-requests/cpython that referenced this issue May 6, 2024
@terryjreedy
Copy link
Member

The current sundar section makes no mention of a blanket preemption, but does doc that there have been additions, implying possible future additions. There is one current use of a name with internal underscores. This might be classified as type-feature, but type-bug is not clearly wrong.

I think the restriction should be loosened at least in 3.13 if possible and documented whatever it is in each version.
@ethanfurman

chrysn added a commit to chrysn-pull-requests/cpython that referenced this issue May 7, 2024
chrysn added a commit to chrysn-pull-requests/cpython that referenced this issue May 7, 2024
chrysn added a commit to chrysn-pull-requests/cpython that referenced this issue May 7, 2024
@terryjreedy terryjreedy added type-feature A feature request or enhancement and removed type-bug An unexpected behavior, bug, or error labels May 7, 2024
SonicField pushed a commit to SonicField/cpython that referenced this issue May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants