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

Fix namedtuple parent #2555

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

temyurchenko
Copy link
Contributor

A part of getting rid of non-Module roots, see #2536

Copy link

codecov bot commented Sep 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.08%. Comparing base (a99967e) to head (5b637fa).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2555      +/-   ##
==========================================
+ Coverage   93.05%   93.08%   +0.02%     
==========================================
  Files          93       93              
  Lines       11050    11046       -4     
==========================================
- Hits        10283    10282       -1     
+ Misses        767      764       -3     
Flag Coverage Δ
linux 92.96% <100.00%> (+0.02%) ⬆️
pypy 93.08% <100.00%> (+0.02%) ⬆️
windows 93.06% <100.00%> (+0.02%) ⬆️

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

Files with missing lines Coverage Δ
astroid/brain/brain_namedtuple_enum.py 93.86% <100.00%> (+0.98%) ⬆️

end_col_offset=None,
)
]
tuple_base = util.safe_infer(_extract_single_node("tuple"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you inferring here? Shouldn't this just be the nodes.Name for tuple? Similar to the comment you make about EnumMeta preferably being the Name reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My motivation for using the actual definition instead of a Name was to avoid the situation where the actual tuple is shadowed, and thus the Name refers to something different.

However, looking at it my current implementation doesn't achieve that. A better way to do it would be something like tuple_base = builtin_module["tuple"]. If you think that my worry above is weakly-founded, I can revert to a Name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I talk about it in some more detail in the commit message)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah makes sense. I think your idea of doing builtin_module["tuple"] makes the most sense. Let's do that!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, actually it appears that tuple_base: nodes.Name = _extract_single_node("tuple") works pretty well. It's not going to be shadowed, because it belongs to an empty module. Should we go with that?

@temyurchenko temyurchenko force-pushed the fix-namedtuple-parent branch 2 times, most recently from 43e8c5b to 29d6e84 Compare September 10, 2024 20:30
DanielNoord
DanielNoord previously approved these changes Sep 11, 2024
Copy link
Collaborator

@DanielNoord DanielNoord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I think I'd like @Pierre-Sassoulas to also have a look here

@temyurchenko
Copy link
Contributor Author

(removed outdated comment, "#set base class=tuple")

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like those kind of change would benefit from being tested in pylint using the primers. This is not done automatically it would be bad to have surprises after we release a version of astroid. Do you know how to do that @temyurchenko ? (pip install a branch of astroid in editable mode then launch pylint's tests then pylint's primer)

@temyurchenko
Copy link
Contributor Author

I feel like those kind of change would benefit from being tested in pylint using the primers. This is not done automatically it would be bad to have surprises after we release a version of astroid. Do you know how to do that @temyurchenko ? (pip install a branch of astroid in editable mode then launch pylint's tests then pylint's primer)

I'll try and report

it's a part of the campaign to get rid of non-module roots
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants