always use the local name when building definitions

[temyurchenko]

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

Sometimes a class accesses a member by a different name than
"name" of that member: in pypy3 list.__mul__.__name__ == "__rmul__".

As a result, in the example above we weren't able to find
"list.mul", because it was recorded only as "list.rmul".

it's a part of the campaign to get rid of non-module roots

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.05%. Comparing base (a99967e) to head (1194bcf).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2564      +/-   ##
==========================================
- Coverage   93.05%   93.05%   -0.01%     
==========================================
  Files          93       93              
  Lines       11050    11049       -1     
==========================================
- Hits        10283    10282       -1     
  Misses        767      767              

Flag	Coverage Δ
linux	92.94% <100.00%> (-0.01%)	⬇️
pypy	93.05% <100.00%> (-0.01%)	⬇️
windows	93.04% <100.00%> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
astroid/raw_building.py	94.90% <100.00%> (-0.02%)	⬇️

[DanielNoord]

For posterity the localname stuff was introduced in 4cdfc82

If I understand it correctly, when doing the initial object_build we try to access getattr(obj, name).name However, this can fail so the code was changed to also have a reference to name itself as a fallback.

Now that I'm re-reviewing this. Could you add a link to the commit in the NB comment?

[temyurchenko]

Now that I'm re-reviewing this. Could you add a link to the commit in the NB comment?

Hmm, the commit above answers the question «why have local name» with «because sometimes .__name__ is missing». However, my question is «why possibly we might want to use .__name__ over of local name».

[temyurchenko]

If I understand it correctly, when doing the initial object_build we try to access getattr(obj, name).name However, this can fail so the code was changed to also have a reference to name itself as a fallback.

It doesn't exactly fail, it's just that in pypy they do stuff like list.__mul__ = list.__rmul__. And now even though list.__mul__ is accessed via __mul__ localname, it's actually the __rmul__ object with the corresponding .__name__.

[DanielNoord]

So I found the original bug report:
https://www.mail-archive.com/python-projects@lists.logilab.org/msg00009.html

I think the fix as in this PR is still correct: we should always use __name__ as that is the name of the object we are building. localname should only be used a fallback if __name__ isn't set due to a c-extension not behaving like regular Python code.

What do you think @temyurchenko?

Edit: Upon reading the code again I think the change to object_build_methoddescriptor is actually incorrect. We should still prefer __name__ there

[temyurchenko]

So I found the original bug report: https://www.mail-archive.com/python-projects@lists.logilab.org/msg00009.html

I think the fix as in this PR is still correct: we should always use __name__ as that is the name of the object we are building. localname should only be used a fallback if __name__ isn't set due to a c-extension not behaving like regular Python code.

What do you think @temyurchenko?

Edit: Upon reading the code again I think the change to object_build_methoddescriptor is actually incorrect. We should still prefer __name__ there

Looking at the linked report, the issue was the following: symbols from C modules don't have __name__, thus we fail if we try to use __name__.

It's still not clear to me, why we should prefer __name__ over localname. I showed an example above where preferring __name__ over localname leads to a bug and is just incorrect logically. If the class chooses to use a symbol under a different name (i.e. the localname), that's how we should look it up. Otherwise, the symbol isn't going to be found.

Why should we prefer __name__?