Descriptor decorated constructors lead to false positives in ignored imports

[ethereon]

Consider the following valid Python code:

import numpy

class Wrapper:
    def __init__(self, func):
        self.func = func

    def __get__(self, instance, owner):
        return lambda **kwargs: self.func(instance, wrapped=True, **kwargs)

class Foo:
    @Wrapper
    def __init__(self, **kwargs):
        print(f'{kwargs}')

Foo(bar=numpy.nan)

Pyright (tested with 1.1.41) will incorrectly report the numpy import as unused.

While I'm not very familiar with Pyright's internals, a quick debug session indicates the following:

validateConstructorArguments invokes validateCallArguments for Foo(bar=np.nan). The inferred type of __init__ is an object (Wrapper) and it attempts to look up Wrapper.__call__. This failed call to getTypeFromObjectMember doesn't set argumentErrors to true (not sure if that's intentional), but consequently, the numpy reference in the argument doesn't get added to accessedSymbolMap.

[erictraut]

Thanks for the bug report. You've actually uncovered three distinct bugs, all of which will be fixed in the next version of Pyright.

Bug #1: When an object is not callable (i.e. doesn't have a __call__ method), an attempt to call it should generate an error.

Bug #2: When a call expression generates errors (such as the one above), the arguments should still be evaluated so they are type-checked and marked as accessed.

Bug #3: When an object has a __get__ method, it should be treated as callable even though there is no __call__ method.

Your code will run, but this is a very strange way to make the Wrapper class callable. It took me a while to reason out why this code runs without generating an exception. It's because the Python interpreter attempts to look up a __call__ attribute, but your __get__ method intercepts this lookup and returns a lambda instead.

A much cleaner way to implement this is to replace your __get__ method with the following code:

    def __call__(self, **kwargs):
        return self.func(self, wrapped=True, **kwargs)

Pyright would have correctly handled this formulation.

[ethereon]

Thanks for the quick response!

My example was a bit contrived (and I agree that overall it's a fairly convoluted usage), but there are actual examples in the wild that use this idiom. For instance, this one uses it to generate lazily code-gen dataclasses.

[erictraut]

This is now addressed in Pyright 1.1.42, which was just published.