One pylint warning, two identical lines: astroid #3077 and the generator that ate its fallback

An issue filed against `typing.cast` turned out not to involve cast handling at all. `infer_typing_cast`, tested on its own, behaves identically for both call styles ^[6], which moves the search upstream of `cast()` entirely: whatever differs, differs before the cast is ever evaluated.

What differs is dispatch. Written explicitly, `self.separator.run()` resolves to a `BoundMethod`, and astroid walks into the body of `Base.run()` and evaluates the cast correctly ^[8]. Written implicitly, `self.separator()` resolves to the `Instance` and goes through `BaseInstance.infer_call_result()` in `astroid/bases.py`, the path that exists to resolve the `__call__` dunder ^[9].

That function opens with an optional attempt to treat the call as a plain attribute lookup on the callee, iterating `igetattr(caller.func.attrname)` when the caller is a `Call` whose `func` is an `Attribute` ^[10]. For `self.separator()`, `attrname` is `"separator"`, and it is looked up on the `Base` instance, which has no such attribute, so the lookup raises `InferenceError` ^[11]. Because `infer_call_result` is a generator, that exception does not just fail the optional branch. It terminates the whole function, including the loop below it that does the real `__call__` resolution ^[12]. The comment sitting above that second loop describes the behaviour the exception prevents ^[13]. Nothing surfaces to the user: no traceback, just one fewer inference candidate than the source promises.

The author found this by monkey-patching pylint's own inference calls at runtime rather than editing installed files, in order to watch which path each syntax actually took ^[7].

Now the arithmetic, which the post does not spell out. Before the patch, the reproducer emits one `no-member` warning, on the explicit `.run()` line at 35:15 ^[5]. After it, the same file emits two, at 31:15 and 35:15, with the same message ^[15]. On the post's own account that both lines are equivalent and `sep` is a plain `str` at runtime ^[4], the count of wrong warnings goes from one to two ^[17]. The patch fixes the inconsistency; it does not fix the inference. The issue itself concedes that `Instance of <enclosing class>` is not necessarily the most precise answer for this expression ^[16].

That is still worth having, because an inconsistent engine is worse to work with than a uniformly wrong one. A warning that appears on one of two structurally symmetric lines ^[2] cannot be triaged by staring at the line, and a developer who checks the unflagged twin will conclude, reasonably and wrongly, that something about their own code differs. Once both report the same thing, the remaining disagreement is between astroid and `cast`, which is a bug with one address.