Python base-class inheritance emits an Implements edge (extract.rs::python_edges class_definition arm). But the resolver's preferred_matches for implements prefers trait/interface kinds, not class — so for a Python base (kind class), the Implements edge can mis-resolve to a same-named non-class symbol elsewhere in the index, or fall back ambiguously.
Impact is bounded today: python_edges ALSO emits a ReferencesType edge to the same base, and ReferencesType resolution DOES prefer type/class kinds — so the inheritance target is still captured. The risk is only the Implements edge resolving to the wrong symbol.
Options:
- Include class-like kinds in the
implements resolution preference for Python (cross-language change — verify it doesn't mis-prefer in Kotlin/TS where implements targets interfaces).
- Or a Python-specific edge-kind/preference.
Context: Codex review round 3 on #167. Deferred from #167 because it's a resolver-side, cross-language change that deserves its own review; the base is already captured via ReferencesType in the meantime.
Python base-class inheritance emits an
Implementsedge (extract.rs::python_edgesclass_definition arm). But the resolver'spreferred_matchesforimplementspreferstrait/interfacekinds, notclass— so for a Python base (kindclass), theImplementsedge can mis-resolve to a same-named non-class symbol elsewhere in the index, or fall back ambiguously.Impact is bounded today: python_edges ALSO emits a
ReferencesTypeedge to the same base, and ReferencesType resolution DOES prefer type/class kinds — so the inheritance target is still captured. The risk is only theImplementsedge resolving to the wrong symbol.Options:
implementsresolution preference for Python (cross-language change — verify it doesn't mis-prefer in Kotlin/TS whereimplementstargets interfaces).Context: Codex review round 3 on #167. Deferred from #167 because it's a resolver-side, cross-language change that deserves its own review; the base is already captured via ReferencesType in the meantime.