When a class is wrapped with a decorator that adds attributes to the class, the added attributes are not recognized by the language server

[ytxmobile98]

Environment data

• Pylance version: v2024.8.1
• OS and version: Ubuntu 22.04.4 LTS
• Python version: 3.10.12

Code Snippet

I recently ran into this issue when I needed to use a class decorator to add custom attributes (methods and properties) to it. As seen below, when I added a decorator (wrap) along the class Foo, it adds a class method bar and a data attribute one to it. But when I then reference these two added attributes, the editor shows red squiggles underneath, and jumping to the initial definitions in the decoration function or auto-completing these attributes are also not possible. Here is a minimal example to reproduce it:

def wrap(cls):
    @classmethod
    def bar(cls):
        print(cls.__name__)

    cls.bar = bar
    cls.one = 1

    return cls


@wrap
class Foo:
    @staticmethod
    def foo():
        print('foo')


def main():
    Foo.foo()
    Foo.bar()
    print(Foo.one)

    print(Foo.__dict__)


if __name__ == '__main__':
    main()

Repro Steps

1. Write the code above in VSCode
2. Save it as main.py
3. See how it marks errors

Expected behavior

The references to bar and one should work normally, i.e. the language server should recognize them as corresponding to what I defined above.

Actual behavior

The language server sees them as unknown attributes.

[erictraut]

Converting this to a discussion topic since it isn't a bug.

[erictraut]

While class mutations like this are possible in a dynamic language like python, they are not supported by type checkers. Such modifications typically represent bugs in code, since they're writing to attributes that are not part of a class's contract. Static type checkers are designed to detect and prevent such bugs.

There is a proposed feature in the Python type system that could accommodate this use case. It's called an "intersection type". However, this feature hasn't yet been fully spec'ed, and it will likely be years before it's formally added to the type system. In the meantime, there's no good way to express the mutated class type in your code.

Your options are:

1. Abandon the use of this type of mutation by using a formal class hierarchy with a mixin class.

class BarOneMixin:
    @classmethod
    def bar(cls):
        print(cls.__name__)

    one: ClassVar[int]

class FooBase:
    @staticmethod
    def foo():
        print("foo")

class Foo(FooBase, BarOneMixin):
    pass

2. Create a protocol class that describes the "bar" method and "one" class variable, and use that protocol class as the return type for the wrap function. The type checker will then allow you to access the bar and one attributes on the resulting wrapped class, but the type checker won't allow you to access any of the attributes defined on the wrapped class.

class BarOneProto(Protocol):
    @classmethod
    def bar(cls):
        print(cls.__name__)

    one: ClassVar[int]


def wrap(cls) -> BarOneProto: ...

3. Specify that wrap returns the type Any. This will eliminate all type checker errors, but it will also eliminate all language server features (e.g. completion suggestions) that depend on type information.

def wrap(cls) -> Any: ...

[ytxmobile98]

The issue came to my attention when I initially wanted to use the dataclasses-json library to read some JSON config data into Python classes. This library provides the @dataclass_json decorator to add methods like to_json(), to_dict(), from_json(), from_dict() to classes and instance variables. Most importantly it does not create new classes when adding these methods to existing classes, but only does an in-place modification instead.

I initially suspected if it was a design flaw of the library. So I wrote the minimal reproducible example above and saw that it was not a library-specific issue, but a general issue with class decorators.