Python: bare method calls (`x.get(...)`) bind to a same-named module-level function — false `calls` edges create a god node (reproduces on every 0.9.x I tested)

[dispather]

Summary

In Python extraction, an unresolved attribute call x.get(k) is resolved by bare name to a module-level function get defined in the project, producing a calls edge that does not exist. Any codebase that both defines a short, common function name (get, set, run, …) and uses the same method name on dicts/clients gets that function inflated into the #1 god node.

This is the Python call-site counterpart of #2241 (JS/TS closure arguments, fixed in 0.9.29) and looks closely related to #2315 (Python @receiver.name(...) decorators binding to an unrelated module-level function of the same bare name) — possibly the same bare-name fallback in the Python resolver.

Minimal reproduction (~30s)

fixture.py, alone in an empty directory:

def get(k):
    """Module-level function that shares a name with dict/mapping .get."""
    return k


class Store:
    def __init__(self):
        self.store = {}

    def read(self, k):
        return self.store.get(k)


def other(d):
    return d.get('x')


def real():
    return get('real')

graphify .

Then count calls edges whose target is the node labelled get() (the module-level function; methods are labelled .name()):

import json
g = json.load(open("graphify-out/graph.json"))
t = {n["id"] for n in g["nodes"] if n.get("label") == "get()"}
print([l for l in g["links"] if l.get("relation") == "calls" and l["target"] in t])

Expected: 1 edge — real() -> get().
Actual: 3 edges — real() -> get(), other() -> get(), Store.read() -> get().

self.store.get(k) is a dict lookup and d.get('x') is a call on an unannotated parameter; neither can be resolved to the module-level get, but both are bound to it.

Version sweep

Same fixture, run via uv tool run --from graphifyy==<version> graphify .:

version	inbound calls into get()	verdict
0.9.32, 0.9.31, 0.9.30, 0.9.29, 0.9.28, 0.9.27, 0.9.26, 0.9.24, 0.9.22, 0.9.20, 0.9.17, 0.9.14, 0.9.13, 0.9.5, 0.9.0	3	❌ buggy

15/15 buggy — so this is not a regression introduced by a recent release. (0.8.0 could not be installed here: dependency resolution fails.)

Impact on a real repo

On a ~3.3k-node Python project, one rebuild made the project's get() in settings_store.py jump from degree 27 to 149, taking the #1 god-node slot. A single module contributed 42 of those edges while never importing settings_store — it simply contains 127 .get( call sites. Across that rebuild, 122 of the 200 newly-added edges (61%) were false edges of this shape (net edge count 6,927 → 7,110).

Downstream, this corrupts god-node ranking, explain <node>, and community assignment, and there is no version to pin to as a workaround.

Suggested direction

Don't fall back to bare-name matching for attribute calls when the receiver is unresolved. If a fallback is needed for recall, emit it at a lower confidence and/or as a distinct relation so consumers can filter it, rather than as a plain calls edge.

Environment

• graphify 0.9.32 (and the 14 older versions above), installed via uv tool / uv tool run
• macOS 26.5.2 (arm64), uv-managed CPython 3.13.12

[dispather]

0.9.33 still reproduces — 16/16

Re-ran the fixture from the report against 0.9.33, which released after this was filed.

version	inbound calls into get()	verdict
0.9.33	3	✗

To rule out a stale environment, I captured the 0.9.32 baseline in the same shell session immediately before upgrading:

graphify --version            # 0.9.32
  -> 3 inbound calls edges into get()
uv tool upgrade graphifyy     # 0.9.32 -> 0.9.33
graphify --version            # 0.9.33
  -> 3 inbound calls edges into get()

The three edges are unchanged in identity, not just in count:

other() -> get()
real()  -> get()
.read() -> get()

Only real() -> get() is genuine. So this is not a partial fix — resolving either d.get('x') or self.store.get(k) alone would have left 2 — and the node labelling is unchanged (get() for the module-level function, .read() for the method), so it isn't a schema shift masking a fix either.

That makes it 16 of 16 versions tested: the 15 in the sweep above plus 0.9.33.

Why this one matters more than the count

The sweep already established there's no version to pin to. What 0.9.33 adds is that a release landed after the report with the bare-name fallback untouched, so downstream consumers can't treat "wait for the next release" as a workaround either. We've settled on read-time filtering — treating degree spikes on short common method names (get/set/run) as suspect in god-node ranking, explain, and community output — and we re-adjudicate only when the version rises. Happy to re-run the fixture on any branch or pre-release if that would help confirm a fix.

Environment

• graphify 0.9.33 via uv tool upgrade graphifyy
• macOS 26.5.2 (arm64), uv-managed CPython 3.13.12

[safishamsi]

Fixed in v0.9.39. A Python member call on an untyped receiver (x.get(...)) no longer binds by name alone to a same-named module-level function. Such a call is now deferred to the evidence-gated resolver and only resolves with receiver-type / import / self/cls/super evidence (matching the TypeScript fix from 0.9.37), so the false high-confidence edges that formed a get() god node are gone; super().method() still resolves. Thanks @EZZEASY for the fix (PR #2586).