Pylance attribute completion for typing.Union expressions includes false positive attribute names

[doeblerh]

Describebe the bug
Pylance's attribute completion for expressions whose annotated/inferred type is a typing.Union includes attribute names that pylance itself knows not to be valid for all types of the union.

Code or Screenshots

class A:
    a: int
    m: int

class B:
    b: int
    m: int

def f(x: A | B):
    return x.CURSOR_HERE

Since x has type A | B, i.e., isinstance(x, (A, B)), the correct set of x's attributes is intersection(attrs(A), attrs(B)), i.e., {m ![completed](https://github.com/microsoft/pyright/assets/21227649/57387b95-3586-4da0-b398-9e72d9565f95) ![completion](https://github.com/microsoft/pyright/assets/21227649/8442d607-cd89-4bf0-9c4b-305f9d692447) } (plus dunder stuff). Pylance completion, however, offers a, b, m, <dunder stuff> (see screenshot attached), i.e. seems to build the union of the available attributes. If one selects x.a, pylance immediately and correctly reports "error: Cannot access member "a" for type "B".

It always feel a bit like being fooled in that situation: first, pylance is suggesting me some attribute names and if I decide to use one of its completion options, it turns red and tells me: WRONG!

Expected Behavior
Attribute completion of union types should consist of the intersection of attribute completion candidates of the union's elements. In the example above, x. should complete only to {m}.

VS Code extension or command-line
Pylance: v2023.10.10
in Visual Studio Code

Version: 1.83.0
Commit: e7e037083ff4455cf320e344325dacb480062c3c
Date: 2023-10-03T16:11:49.843Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 5.15.0-83-generic snap

[erictraut]

The current behavior is by design, not a bug. I think most users of pyright and pylance want to see attributes that are available for all subtypes within a union rather than the intersection of available attribute types. This is especially true for users who don't enable type checking diagnostics (which is the majority of people who use pylance). I'll also note that pyright's current behavior is consistent with language servers for other programming languages that support unions.

Since this is a request for a language server feature, I'll leave it to the pylance team to make a final decision about what to do with it. They may close it or leave it open as a discussion topic for additional user input. @rchiodo or @debonte, could you transfer this to the pylance-release project? Thanks!

[rchiodo]

Converting this to a discussion item.

If typeCheckingMode is basic or strict, perhaps this should use the intersection. Otherwise if typeCheckingMode is off, we'd leave it as the union.

[doeblerh]

I agree, I would appreciate to have that behavior configurable. I definitely see the point that some people would still like to see the union of attributes. I think this strongly depends on the degree to which a code base is typed. In partially/gradually typed code it makes sense to see all possible attributes. In completely typed code, however, where one might even have git hooks that prevent type-erroneous code from being merged, it makes hardly sense to complete attribute names that unconditionally imply type errors.

However, I would favor the intersection semantic to be implemented by means of applying a filter on the current union result: Not all types are suitable for computation of comprehensive candidate sets to be intersected. Especially if we think of generic types with heavily overloaded __getattr__/__setattr__ with complex TypeVar-depending self annotations.