Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
astroid pull request #3242 proposes a change to make two call forms follow a more consistent inference path, but it is still an open proposal—not a merged or released fix in the status described here. The proposed change catches an InferenceError from an optional early lookup in BaseInstance.infer_call_result; a reviewer objected that inference errors should not be swallowed.
What the reported bug looks like
The issue is described as: “Bug: identical typing.cast expressions yield different inferences depending on how they are reached.” In the author’s example, the implicit call self.separator() and the explicit method call self.separator.run() have structurally similar implementations and are runtime-equivalent in that example. Yet astroid follows different inference routes, and pylint reports an inconsistent no-member result.
These reproduction details come from the author’s account; they have not been independently reproduced here. The important distinction is between what Python executes and what astroid can infer while analyzing the code: equivalent runtime behavior does not guarantee that two syntactic forms pass through the same inference logic.
Where the inference paths diverge
| Call form | Route described by the author | Reported consequence |
|---|---|---|
self.separator() |
BaseInstance.infer_call_result |
An optional early attribute lookup may raise InferenceError before inference reaches __call__. |
self.separator.run() |
A bound-method route | It does not take the same instance call-result route described for the implicit call. |
According to the author, BaseInstance.infer_call_result first attempts an optional lookup using the call’s attribute name against the inferred instance. If that lookup raises InferenceError, the generator ends before the later __call__ inference path can run. That early exit is the proposed mechanism behind the discrepancy—not a demonstrated defect in Python’s runtime call behavior.
#1 Best Overall
What PR #3242 proposes
The patch wraps the optional lookup in an InferenceError catch. If the lookup fails, inference can continue toward the later __call__ path instead of ending immediately. The goal is to make the implicit and explicit forms behave more consistently in inference.
The PR also adds a regression test named test_infer_call_result_dunder_call_consistent_with_attribute_call in tests/test_inference.py. The author reports running the test suite; that result is author-reported, not an independent test run.
Why the proposed catch is contested
Catching the exception may let inference proceed in this case, but catching it broadly could also conceal a different, legitimate inference failure. Reviewer DanielNoord objected: “This does not seem correct. An inference error should not be swallowed.” The PR author acknowledged that a broad catch could hide other errors and asked whether a narrower or different approach would be preferable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
That objection matters because consistency is not the same as correctness. Making both call forms produce the same inference would address the disagreement between paths, but it would not by itself prove that the shared inferred result is accurate. The review discussion therefore concerns both the reported symptom and whether the proposed error handling preserves meaningful failures.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Is the astroid bug fixed?
No merged or released fix is established by the cited upstream status. PR #3242 was open at the time checked, and issue #3077 appeared open. The proposal is under review, with a substantive objection about swallowing InferenceError; it should not be described as an accepted fix. Status can change, so consult the official pull request and the astroid issues page for their current state.
astroid is a Python source representation library used by pylint and other projects. The project description is available in the official repository. The available account explains the suspected mechanism, but does not establish independent reproduction or a final upstream resolution.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
