Tracking class updates

[savchenko]

Say we have a file extensions.py where:

class Foo(some):
    def __init__(self, bar=None):
        self.bar = None

foo_instance = Foo()

in the main.py we:

from extensions import foo_instance

foo_instance(bar=something)

Then, to avoid circular import, in whatever.py which is imported by main.py:

from extensions import foo_instance

foo_instance.something.some_method()

The problem

Pyright does not know that foo_instance.something exists and reports reportOptionalMemberAccess.

Is there a solution? Related to viniciuschiele/flask-apscheduler#249

[erictraut]

In your example above, foo_instance isn't callable, so I don't see how this would work. I'm guessing that your example is incomplete.

If you want to use static typing, attributes on a class must be declared. If you're adding dynamic attributes to an object that are not declared, then a static type checker will not know about them and will complain if you attempt to access them.

There are many ways to eliminate circular dependencies in your code, most of them involving refactoring. The technique you're using here looks very hacky. I'd need to understand your scenario better to offer more concrete suggestions.

[savchenko]

The example provided is a bastardised version of the application factory, pattern widely used in Flask applications.

The issue I have linked in the original post is an official example of correct use by one of the Flask extensions.

I fully appreciate the challenge, as at time of import in whatever.py, linter would not know that foo_instance.something exists.

Here is what is happening:

[erictraut]

This is still too abstract for me to offer much in the way of advice. My initial thought is that it looks like Foo should be a generic class.

This pattern also looks really fragile since foo_instance appears to be a singleton, and yet it's mutable. What if two modules import foo_instance and call foo_instance(something)? The last one wins? Perhaps it would make sense to revisit the entire design.

[savchenko]

Let me explain using concrete example. Here is the Foo from above:

class APScheduler(object):
    """Provides a scheduler integrated to Flask."""

    def __init__(self, scheduler=None, app=None):
        self.app = None
        if app:
            self.init_app(app)

and its instance:

from flask_apscheduler import APScheduler

scheduler = APScheduler()

Now, let's look at init of an actual, working application:

from .extensions import scheduler

def create_app():
    """Create a new app instance."""

    app = Flask(__name__)
    scheduler.init_app(app)

if __name__ == "__main__":
    app.run()

From the above we see that during the runtime scheduler.app.* will reference the current application.

However, from linter's perspective this is not the case and, for example, this file lights up like a Christmas tree when checked by PyRight.

from .extensions import scheduler

def job_missed(event):
    """Job missed event."""
    with scheduler.app.app_context():  # PyRight does not know about scheduler.app.*
        print(event)

[erictraut]

Yeah, this pattern won't work with static type checking. As I mentioned above, there are other reasons why this is a bad design pattern, so I encourage you to rethink it. If you can't change it for historical reasons, then you'll need to add some hacks if you want a static type checker to know about these types. This would likely involve calls to typing.cast.