This is a really minor bug.

In enum.py the function _is_sunder(name) fails on empty string with an IndexError.

As a result, attempting to create an Enum with an empty string fails.

>>> from enum import Enum
>>> Yay = Enum('Yay', ('', 'B', 'C'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\Python37\lib\enum.py", line 311, in __call__
    return cls._create_(value, names, module=module, qualname=qualname, type=type, start=start)
  File "C:\Program Files\Python37\lib\enum.py", line 422, in _create_
    classdict[member_name] = member_value
  File "C:\Program Files\Python37\lib\enum.py", line 78, in __setitem__
    if _is_sunder(key):
  File "C:\Program Files\Python37\lib\enum.py", line 36, in _is_sunder
    return (name[0] == name[-1] == '_' and
IndexError: string index out of range
>>>

Expected behavior is for it to not fail, as Enum accepts wierd strings. Example:

>>> from enum import Enum
>>> Yay = Enum('Yay', ('!', 'B', 'C'))
>>> getattr(Yay, '!')
<Yay.!: 1>
>>>

Transcript of lines 26 to 39 of enum.py:

def _is_dunder(name):
    """Returns True if a __dunder__ name, False otherwise."""
    return (name[:2] == name[-2:] == '__' and
            name[2:3] != '_' and
            name[-3:-2] != '_' and
            len(name) > 4)


def _is_sunder(name):
    """Returns True if a _sunder_ name, False otherwise."""
    return (name[0] == name[-1] == '_' and
            name[1:2] != '_' and
            name[-2:-1] != '_' and
            len(name) > 2)

Solution 1: Replace with:

def _is_dunder(name):
    """Returns True if a __dunder__ name, False otherwise."""
    return (len(name) > 4 and
            name[:2] == name[-2:] == '__' and
            name[2] != '_' and
            name[-3] != '_')


def _is_sunder(name):
    """Returns True if a _sunder_ name, False otherwise."""
    return (len(name) > 2 and
            name[0] == name[-1] == '_' and
            name[1:2] != '_' and
            name[-2:-1] != '_')

In this solution, function '_is_dunder' was also altered for consistency.
Altering '_is_dunder' is not necessary, though.

Solution 2: Replace with:

def _is_dunder(name):
    """Returns True if a __dunder__ name, False otherwise."""
    return (name[:2] == name[-2:] == '__' and
            name[2:3] != '_' and
            name[-3:-2] != '_' and
            len(name) > 4)


def _is_sunder(name):
    """Returns True if a _sunder_ name, False otherwise."""
    return (name[:0] == name[-1:] == '_' and
            name[1:2] != '_' and
            name[-2:-1] != '_' and
            len(name) > 2)

In this solution, function '_is_sunder' was altered to follow
the style used in function '_is_dunder'.

Typo fix on solution 2:

def _is_sunder(name):
    """Returns True if a _sunder_ name, False otherwise."""
    return (name[:1] == name[-1:] == '_' and
            name[1:2] != '_' and
            name[-2:-1] != '_' and
            len(name) > 2)

Hi @Maxpxt, I think your first solution is appropriate, do you want to open a new pull request with your solution and an appropriate test case?

I agree with Rémi Lapeyre.

For reference, the len() check and current tests were added under bpo-19156.

Yes, the first solution will be fine. Maxwell, can you create a github pull request with that?

I'm not sure if Maxwell is still working on this issue, but may I pick it up? I can submit a PR within the day.

Let's give Maxwell until the 14th (so a week from when I asked him to turn his code into a patch) and if nothing from him by then you are welcome to take it over.

Got it, makes sense. Thank you. New contributor here :)

Hi,

I have created the PR for Maxwell.

After tomorrow, if we have no news from him, I propose to you to update/comment the PR. Of course, I will add a co-authored-by field in the commit.

Thank you, Stéphane. I submitted a change request to your PR just now.

Hi Brennan,

Normally, you wanted to work on this issue and you have waited for one week after the last message of Maxwell.

Do you want to work on this issue and submit your PR?

Have a nice day,

Stéphane

Yes, I will submit a new PR today.

Thank you for your contribution.

Have a nice day,

The changes to _is_sunder and _is_dunder look good, but there is a problem with the underlying assumptions of what Enum should be doing:

• nameless members are not to be allowed
• non-alphanumeric characters are not supported

In other words, while _is_sunder should not fail, neither should an empty string be allowed as a member name. This can be checked at line 154 (just add '' to the set) -- then double check that the error raised is a ValueError and not an IndexError.

For the strange character portion, use some non-latin numbers and letters to make sure they work, but don't check for symbols such as exclamation points -- while they might work, we are not supporting such things, and having a test that checks to make sure they work suggests that we do support it.

New changeset 8b914d2 by Miss Islington (bot) (Brennan D Baraban) in branch 'master':
bpo-35899: Fix Enum handling of empty and weird strings (GH-11891)
8b914d2

Thank you, everyone!

New changeset 8755f0a by Miss Islington (bot) in branch '3.7':
bpo-35899: Fix Enum handling of empty and weird strings (GH-11891)
8755f0a