Select last inferred value for usage

[Alphadelta14]

Fixes the underlying issue associated with #3825, where a module with two function definitions in a third party should have the last definition selected instead of the first.

In the numpy.lib case, there are two functions with the same name in the same scope. The first is selected resulting in bad signatures:

# from .function_base import *
def unique(x):

# from .arraysetops import *
def unique(ar, return_index=False, return_inverse=False,
           return_counts=False, axis=None):

This was fixed upstream by numpy by removing the first definition, but this was definitely something bothering me because the behavior did not match python behavior properly. I hope it fixes other folks' issues as well.

At the same time, safe_infer is a heavily used function in the pylint codebase and should be subject to additional scrutiny.

Most inference cases are expected to have a single inferred result, so they wouldn't be affected by this.
For inference cases where two different types are seen, we return None. This is the same behavior.

In the case of multiple inference results of the same pytype, this behavior changes:
FunctionDef: later function definition is chosen (seems like fixed behavior)
Import by name: last import with same name wins (seems like fixed behavior)
Assign: last value inferred (seems like fixed behavior)
Sequence: last item inferred instead of first (different behavior, still one-of-many).
Returns: last return value used (different behavior than before, but still using one-of-many).

Steps

Todo after acknowledgement

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.

Description

Type of Changes

	Type
✓	🐛 Bug fix

Related Issue

Closes #3825

[Pierre-Sassoulas]

Hello @Alphadelta14, is this merge request still relevant ? It seems the test do not pass and the issue it aime to fix is closed now.

[Alphadelta14]

At the time of submission, all PRs were failing in the same way. I just rebased to see if the issue was resolved on the main branch.
The underlying issue was addressed in the one-off numpy case, but this resolves it generally instead of requiring each violator to fix it before yielding the correct results.

[Pierre-Sassoulas]

Fixing the problem generically sounds great, thank you for rebasing ! If you have time to finish this MR, I'd be glad to review it.

[Alphadelta14]

@Pierre-Sassoulas, there was an issue with partials where they were being written into the wrong scope which this PR exposed. I addressed it in this PR and also added an upstream fix to astroid pylint-dev/astroid#1097.
If these changes look good to you, I'll gladly go through the rest of the contribution process. :)

[Pierre-Sassoulas]

Nice, let's start with the astroid MR then :)

[Pierre-Sassoulas]

Rebased following the merging of pylint-dev/astroid#1097 and the upgrade of astroid.

[Pierre-Sassoulas]

I'm going to close as the code makes assumption that would result in false positives in particular in this example:

def temp():
    """This is not weird"""
    if True:
        return [1, 2]
    return [2, 3, 4]

def temp2():
    """This is weird, but correct"""
    if True:
        return (1, 2)

    if True:
        return (2, 3)
    return (4, 5)


class UnbalancedUnpacking(object):
    """Test unbalanced tuple unpacking in instance attributes."""

    # pylint: disable=attribute-defined-outside-init, invalid-name, too-few-public-methods
    def test(self):
        """unpacking in instance attributes"""
        # we're not sure if temp() returns two or three values
        # so we shouldn't emit an error
        self.a, self.b = temp()
        self.a, self.b = temp2()
        self.a, self.b = unpack()  # [unbalanced-tuple-unpacking]

We would start emitting an # [unbalanced-tuple-unpacking] for self.a, self.b = temp() which is wrong.