Exclude the _ignore_ attribute from the __members__ container.

[mbyrnepr2]

Closes pylint-dev/pylint#9015

Type of Changes

	Type
✓	🐛 Bug fix
	✨ New feature
	🔨 Refactoring
	📜 Docs

Description

Exclude the _ignore_ attribute from the __members__ container.

Closes #9015

[codecov]

Codecov Report

Merging #2289 (1f9ae72) into main (600229f) will not change coverage.
Report is 4 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2289   +/-   ##
=======================================
  Coverage   92.85%   92.85%           
=======================================
  Files          94       94           
  Lines       11056    11056           
=======================================
  Hits        10266    10266           
  Misses        790      790           

Flag	Coverage Δ
linux	92.66% <100.00%> (ø)
pypy	91.00% <100.00%> (ø)
windows	92.44% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
astroid/brain/brain_namedtuple_enum.py	92.98% <100.00%> (ø)

[Pierre-Sassoulas]

Look like we might need to also exclude _missing_? https://docs.python.org/3/library/enum.html

[mbyrnepr2]

_missing_ is a class method so Pylint is already happy with that naming. What do you think @Pierre-Sassoulas ? Or am I _missing_ something 😆

[Pierre-Sassoulas]

😄 Hmm, and what about _name_ for example ? Just stumbled upon https://docs.python.org/3/library/enum.html#supported-sunder-names (and learnt about sunder vs dunder, nice) it doesn't seem to be all functions in this case.

[mbyrnepr2]

_name_ and _value_ will produce no-member and protected-access for Pylint (unlike the current issue which is invalid-name). I can throw everything into the current MR or separate these cases into another MR for clarity. I guess you prefer to include these 2 in the current MR @Pierre-Sassoulas ?

from enum import Enum


class Fruit(Enum):
    APPLE = 42
    _name_ = 'test'
    _value_ = 'test'

print(Fruit.APPLE._name_)
print(Fruit.APPLE._value_)

python example.py

Traceback (most recent call last):
...
ValueError: _names_ are reserved for future Enum use

pylint example.py

E1101: Instance of 'APPLE' has no '_value_' member (no-member)
W0212: Access to a protected member _value_ of a client class (protected-access)
Instance of 'APPLE' has no '_name_' member (no-member)
Access to a protected member _name_ of a client class (protected-access)
Class constant name "_value_" doesn't conform to UPPER_CASE naming style (invalid-name)
Class constant name "_name_" doesn't conform to UPPER_CASE naming style (invalid-name)

_generate_next_value_: staticmethod
_missing_: class method
_order_: Python 2 only

[Pierre-Sassoulas]

Thank you for investigating ! If I understand correctly _value_ is somewhat similar and _names_ is not ? (It seems ValueError: _names_ are reserved for future Enum use should raise an error message in pylint, but it's very specific to enums, I don't know if we should do it and what message to raise.) If that's the case we could do _ignore_ and _value_ together and _names_ later ? If not let's just do _ignore_ to not overcomplicate things.

[mbyrnepr2]

Ah my example made things confusing I think :)
The Python output _names_ are reserved for future Enum use is referring to sunder names in general (_names_).
Also _value_ and _name_ do produce the invalid-name so I'll see about handling that here(Fruit.APPLE._name_ and Fruit.APPLE._value_ should be expected).

ValueError: _names_ are reserved for future Enum use could be a separate issue I think.

[Pierre-Sassoulas]

Great !

[Pierre-Sassoulas]

Maybe we shouldn't close the pylint issue until astroid is released upgraded and we could clean-up the history and use two commits instead of a squash ? Or we can squash, I'll let you decide :)

[Pierre-Sassoulas]

We actually need to squash for the backport job to work automatically

[github-actions]

The backport to maintenance/2.15.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-maintenance/2.15.x maintenance/2.15.x
# Navigate to the new working tree
cd .worktrees/backport-maintenance/2.15.x
# Create a new branch
git switch --create backport-2289-to-maintenance/2.15.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 43b7f9aa249a8a40d2561736c80953d249a2f158
# Push it to GitHub
git push --set-upstream origin backport-2289-to-maintenance/2.15.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-maintenance/2.15.x

Then, create a pull request where the base branch is maintenance/2.15.x and the compare/head branch is backport-2289-to-maintenance/2.15.x.

[jacobtylerwalls]

Looks like this wasn't backported, so I'll move all the labels and such here and on the pylint issue. Life goes on. :D