Make python linter "understand" metaclass changes

Question

I am playing around with python metaclasses, and trying to write some sort of metaclasses that changes or adds methods dynamically for its subclasses.

For example, here is a metaclass that its purpose is to find async methods in the subclass (that their name also ends with the string "_async") and add an additional "synchronized" version of this method:

class AsyncClientMetaclass(type):
    @staticmethod
    def async_func_to_sync(func):
        return lambda *_args, **_kwargs: run_synchronized(func(*_args, **_kwargs))

    def __new__(mcs, *args, **kwargs):
        cls = super().__new__(mcs, *args, **kwargs)
        _, __, d = args

        for key, value in d.items():
            if asyncio.iscoroutinefunction(value) and key.endswith('_async'):
                sync_func_name = key[:-len('_async')]
                if sync_func_name in d:
                    continue
                if isinstance(value, staticmethod):
                    value = value.__func__
                setattr(cls, sync_func_name, mcs.async_func_to_sync(value))
        return cls

# usage
class SleepClient(metaclass=AsyncClientMetaclass):
    async def sleep_async(self, seconds):
        await asyncio.sleep(seconds)
        return f'slept for {seconds} seconds'

c = SleepClient()
res = c.sleep(2)
print(res)  # prints "slept for 2 seconds"

This example works great, the only problem is that the python linter warns about using the non async method that the metaclass has created (for the example above, the warning is Unresolved attribute reference 'sleep' for class 'SleepClient')

For now, I am adding pylint: disable whenever I am using a sync method created by the metaclass, but I am wondering if is there any way to add a custom linter rule with the metaclass, so the linter will know those methods will be created dynamically.

And are you think there is a better way to achieve this purpose rather than using metaclass?

Thanks!

Answer 1

As put by Chepner: no static code analyser can know about these methods - not linters nor type-annotation checking tools like MyPy, unless you give then a hint.

Maybe there is one way out: static type annotators will consume a parallel ".pyi" stub file, put side by side to the correspondent ".py" file that can list class interfaces, and, I may be wrong, but whatever it findes there will supersede what the toll "sees" on the actual Py file.

So, you could instrument your metaclass to, aside from generating the actual methods, render their signature and the signature for the "real" methods and attributes of the class as source code, and record those as the proper "pyi" file. You will have to run this code once, before the linter can find its way - but it is the only workaround I can think of.

In other words, to be clear: make a mechanism called by the metaclass that will check for the existence and time-stamp of the appropriate ".pyi" file for the classes it is modifying, and generate them. By checking the timestamp, or generating this file only when some "--build" variable is active, there should be no runtime penalties, and static-type checkers (and possibly some linters), should be pleased.