Python: a local built through a module attribute (x = pkg.Cls()) is typed by its variable name #2957

A Python local assigned from a constructor called through a module attribute (client = pkg.AsyncClient()) gets no type. Its method calls then fall to the receiver-name guess, which links client.fetch() to the class named like the variable, Client, even though the code just built an AsyncClient.

# pkg/_client.py
class Client:
    def fetch(self, url):          # line 2
        return url


class AsyncClient:
    async def fetch(self, url):    # line 7
        return url

# pkg/__init__.py
from ._client import Client, AsyncClient

# use.py
import pkg
from pkg import AsyncClient


async def attr_named_client():
    client = pkg.AsyncClient()
    await client.fetch("u")


async def attr_named_c():
    c = pkg.AsyncClient()
    await c.fetch("u")


async def from_named_client():
    client = AsyncClient()
    await client.fetch("u")


async def with_named_client():
    async with pkg.AsyncClient() as client:
        await client.fetch("u")

The instantiates edge for pkg.AsyncClient() resolves correctly in every case. Only the local's type is lost, and the name guess fills the gap with the wrong class.

Reproduced on main at 2577601, with CODEGRAPH_KERNEL=0 and with the native kernel. Linux/WSL2, Node 22.23.2. (3f8e8b0 and 69cddc0 since then touch only Rust and the changelog.)

Where it shows up. httpx (b5addb6) uses exactly this: async with httpx.AsyncClient(...) as client: await client.get(url). Checking every Python calls edge against jedi's goto-definition, about 70 httpx edges disagree this way. Their client.get / post / send / stream / put / options / … calls link to the sync Client methods (httpx/_client.py lines 771–1234) instead of AsyncClient's (lines 1485–1949), for example every request in tests/client/test_async_client.py. Calling a project's own classes through the module (import mymod; x = mymod.Thing()) is common Python, so this isn't specific to httpx.

Expected. Type the local from module.Class(...) the same way as from a directly imported Class(...), and type with …() as x / async with …() as x from the context manager's class. (In another fixture, async with AsyncClient() as client with a directly imported AsyncClient also linked client.get() to Client.get, so the with form may need its own fix.) Failing that, don't let the receiver-name guess answer when the initializer is a call on a project class.

Related: #2946 (the same variable-name guess in TypeScript), #2821, #2175.