Request: Add instructions for enabling Python type checking

[SSteve]

When I enable type checking (in my case in Visual Studio Code) I get a number of Cannot access member "XXX" for type "LocalProxy" (or type "SQLAlchemy"). Some searching turned up other people with the same issue.

In this thread it's suggested to create a stub and perform a cast:

https://github.com/microsoft/pyright/issues/430

This thread has an example (maybe a partial example) of a solution, but I can't figure out how to adapt it to the Microblog project:

https://github.com/microsoft/pylance-release/issues/187

I'd love to see the next Microblog revision (or maybe a blog post) explain how to enable type checking without having to add # type: ignore to the end of every line that has this problem.

Thanks for considering this.

And just to be clear, I think the Flask Mega-Tutorial is an incredible resource. It's easily worth the price. Thanks for all the work you've put into it.

[miguelgrinberg]

@SSteve Correct me if I'm wrong, but the two examples that you mentioned are caused by incorrect type hints in dependencies of this project (Werkzeug and SQLAlchemy). The correct solution in my opinion is to fix the type hints in these libraries, not compensate by adding stubs in this and all the million other projects that use these dependencies. If you think my analysis is incorrect let me know.

[SSteve]

@miguelgrinberg I honestly don't know enough about type hinting in Python to have an informed opinion on the best solution. I'm just starting to try to use it for real (i.e. enabling type checking instead of just adding type hinting to methods I write). I can only make best guesses based on my limited knowledge.

Since db is an instance of SQLAlchemy, it looks like it would make sense for them to be the ones to address that case.

I also run into the same issue with current_user. For example:

Since we are the ones who defined followed_posts(), would it be our responsibility to address type hints for this class?

[miguelgrinberg]

Python is a dynamic language, so you are always going to find that some things cannot be assigned a type. The current_user variable is a perfect example of that. Depending on the application it may evaluate to something of a different type. Even on the same application it can be of different types depending on the situation (user logged in versus not logged in, for example). The problem here is not with followed_posts, but with the fact that the linter does not know what is the type of current_user.

You have to ask yourself what is the purpose of using a linter. Are you using it to get no warnings, or are you using it to find bugs? Linters will always find false positives, this isn't a Python problem but a common aspect of using linters in all languages. The linter is unable to figure this out, but you can look at this code and make an informed decision that this is not a bug and it is a false positive. The correct way to handle this is to tell the linter to ignore this error. I'm not familiar with vscode's linter, but I know that pycharm allows you to do that. I assume vscode does as well.

The approach that you suggest, which is to figure out how to assign a type that somehow makes the linter decide this is okay is the wrong one, in my opinion. It would take a lot more time and effort, and remember that this is code that is working, there are no bugs in this line so you shouldn't be spending time here.

Also, I don't think it would be appropriate for me to add these suppressions myself, because this project isn't associated with vscode or with its linter. Each linter will have its own way of flagging problems, and its own way of suppressing false positives. Each developer should use their own preferred linter.

[SSteve]

Ok, I'll continue to tell the linter to ignore these issues. Thank you very much for your time and insight. I truly appreciate it.