ENB: Fast type checking and studying pylint, mypy, and pyflakes

[Edward K. Ream]

This Engineering Notebook post tells how I am studying pylint, mypy, and pyflakes.

Background

This post contains my discussion with gemini3 about fast linting. 

#4472 contains the summary of my initial prototypes. They all failed quickly :-) In particular, using mypy stubs (stubgen) doesn't seem feasible: stubgen fails on leoApp.py and fails quite slowly.

#4472 now recommends trying to improve pyflakes. pyflakes's code is way simpler and faster than pyflakes.

A new way to study code

In the past, I have cloned or forked repos that I have wanted to study. Now, however, I study tools directly in Python/Lib/site-packages. This is feasible because Leo's Python importers now always work perfectly!  Here are the steps I just used to study pyflakes:

- Do `git init` in Python 3.14's site-packages/pyflakes directory.

- Add all the files and commit. I'll never push this commit, or any others.

- Create  site-packages/pyflakes/pyflakes.leo

- Import all the pyflakes source files as live @clean nodes.

- Write all the imported using Ctrl+Shift+w (write-at-file-nodes).

- Verify that git status reports only that pyflakes.leo has changed.

I now have a safe way to study and modify any of the pyflakes files. I can revert to the original files using `git checkout .`

Frozen modules

Frozen modules can cause problems even when using Python's `-X frozen_modules=off` command-line argument. In particular, that command-line argument doesn't seem to work well with stubgen. I can add traces to stubgen itself, but not to the mypy modules that stubgen calls.  Happily, pyflakes doesn't use frozen modules.

One workflow to study them all

study.cmd contains:

@echo off
cd C:\Python\Python3.14\Lib\site-packages
leo pyflakes/pyflakes.leo mypy/mypy.leo pylint\pylint.leo astroid\astroid.leo

I also define commands to switch to the local repos. For example, cd-pyflakes.cmd:

@echo off
cd C:\Python\Python3.14\Lib\site-packages\pyflakes

Summary

All the tools I've mentioned analyze code by traversing parse trees. But the details are bewilderingly different for each tool. I'll use study.cmd to compare and contrast the tools.

I am not interested in heroic solutions. Improving pyflakes seems like the only way forward.

There is no guarantee of success, but the study itself should be interesting.

Edward

[Edward K. Ream]

On Tuesday, November 25, 2025 at 4:26:15 AM UTC-6 Edward K. Ream wrote:

In the past, I have cloned or forked repos that I have wanted to study. Now, however, I study tools directly in Python/Lib/site-packages. This is feasible because Leo's Python importers now always work perfectly!

Important:  Leo's beautifier doesn't work exactly like black, so round-tripping @clean files requires this setting:

@bool beautify-python-code-on-write = False

Furthermore, I disable code checks with these settings:

@bool check-python-code-on-write = False

@bool run-flake8-on-write = False

Edward

[Edward K. Ream]

On Tuesday, November 25, 2025 at 4:26:15 AM UTC-6 Edward K. Ream wrote:

#4472 now recommends trying to improve pyflakes. pyflakes's code is way simpler and faster than pyflakes.

I have updated #4472 as follows:

- Add  a short example where pyflakes fails to find obvious blunders involving missing attributes. 

- Add a visitor for `ast.ATTRIBUTE` nodes, including a trace that produces the expected output.

This is progress:

- I've demonstrated that I can make and test non-trivial changes to pyflakes.

- There is now a straightforward place to check for missing attributes.

Otoh, actually making such checks (correctly, hehe) might require many other changes.

Summary

It might be possible to help pyflakes find more errors, but a lot more work would be required. Indeed, much of the original design (for pylint, see the issue) would likely have to be repurposed for pyflakes. These are early days.

Edward