no type hint when working with inner class about pylance-release HOT 6 CLOSED

Pyright (the type checker upon which pylance is built) is working correctly here. This isn't a bug.

You have defined two instance methods get_bar and get_a_bar. Instance methods must have a self parameter. If your intent is for these to be static methods, you should add a @staticmethod decorator.

    @staticmethod
    def get_bar() -> bar:
        return foo.bar()

    @staticmethod
    def get_a_bar(a: int = 3) -> bar:
        return foo.bar(a=a)

from pylance-release.

@erictraut
I understand. However, in my case, I will never instantiate the foo class. Therefore, it's acceptable to call get_a_bar() as foo.get_a_bar() without using the @staticmethod decorator.

More importantly, in the previous version of Pylance (or Pyright?), this approach worked just fine.

from pylance-release.

If you want a static type analyzer to understand your code, you will need to decorate these as @staticmethod.

The recent changes were made to increase pyright's conformance to the typing spec. The new behavior is correct, and we don't have plans to revert to the old (non-conformant) behavior.

from pylance-release.

@erictraut
If this behavior is expected, I still believe it is non-conformant.
At least in my opinion, these type hints should either not function at all, or work perfectly. But not partially working.

This means:

• test1 should not be hinted as a bar() object.
• Neither foo.get_bar() nor foo.get_a_bar() should hint their return type as a bar() object.

Alternatively,

• test2 should be hinted as a bar() object, which is what I expect.

from pylance-release.

Add a @staticmethod decorator if you want this to work with pyright.

from pylance-release.

@erictraut
We should not merely avoid triggering bugs as a solution; instead, we should address and resolve the underlying issues that cause the bugs, right?

from pylance-release.