Gradual typing - #1217
Conversation
32341d4 to
7055239
Compare
| ) | ||
|
|
||
| repo_content_prefix = """Here are summaries of some files present in my git repository. | ||
| repo_content_prefix: str | None = """Here are summaries of some files present in my git repository. |
There was a problem hiding this comment.
The type union syntax X | Y is only available in Python 3.10, but Aider still supports Python 3.9.
Instead, this should be
| repo_content_prefix: str | None = """Here are summaries of some files present in my git repository. | |
| repo_content_prefix: typing.Optional[str] = """Here are summaries of some files present in my git repository. |
There was a problem hiding this comment.
On line 1 of this file, I've added
from __future__ import annotationswhich makes sure X | Y is supported on Python 3.9.
There was a problem hiding this comment.
Need to put that in the tests too it looks like:
TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
7055239 to
8058187
Compare
|
I would think that typing an untyped python codebase is exactly the kind of thing that Aider itself would be great at. Typing the edges is trivial, that leads to type errors, fix those, that leads to new type errors, fix those, etc. I also think if it's worth adding type annotations at all, then it's worth bumping to a Python version that supports the latest / greatest versions of them. Aider seems like more of an end-user thing than infrastructure library, seems okay for it to be more aggressive in bumping requirements than a typical library. |
|
Amazing work as this will make aider improving itself even better (from experience llms do quite well with typed code) |
0f49a3d to
6416497
Compare
1a50afe to
77438bb
Compare
|
I rebased on |
|
Have you considered pyright instead? Pyright is fast enough to work in your vscode and neovim live, and can go in your pre-commit. Also we should put typing into the github actions. Personally I think typing will make aider better both in scripting mode (making it more understandable to devs, less likely for bugs) and for self-modification via aider (it will improve the linting loop, and will give more informative repo maps). I'd definitely love to see a blog post about the accuracy of aider edits under properly typed vs untyped code generation. |
ryanpeach
left a comment
There was a problem hiding this comment.
Very minimal IMO. I like it (though I have no authority)
| name: Linting | ||
|
|
||
| on: | ||
| push: |
There was a problem hiding this comment.
Not sure why we need this on push, just PR right?
| - name: Set up Python 3.12 | ||
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: "3.12" |
There was a problem hiding this comment.
Use a matrix like in the other workflows
There was a problem hiding this comment.
What's the benefit of running Mypy on other Python versions than the most recent supported one?
https://github.com/OnScale/aider-stateless/actions/runs/12914071198/job/36012781606?pr=7 |
94c963c to
c568cb0
Compare
|
I've noticed a lot of dead code, dead variables, etc in the codebase. I think this is from aider writing its own code a lot. I think if we are going to have aider write its own code, strong linting is a necessity |
|
Completely agree here @paul-gauthier what are your thoughts? |
4c25a36 to
c74b2d1
Compare
| name: str | ||
| retry: bool | ||
| description: str | ||
| description: str | None |
There was a problem hiding this comment.
Don't forget to add from __future__ import annotations to the top of this file.
- skip some directories - skip 3rd party packages without typing or type stubs - allow untyped globals and class attributes - don't check untyped functions and methods
Also avoid building a list and overwriting it with a tuple.
Here's another stab at adding typing since #639 was closed.
I acknowledge that Paul has expressed that he isn't currently planning to add type hints, and that reviewing type hints would be a burden.
However, I believe this extremely minimal Mypy configuration and a minimal set of changes not only make Mypy pass, but also enable to use it to check some types, and allow development to continue without requiring full type hints everywhere.
Mypy takes over the burden of reviewing type annotations from humans.
Most notably, functions with no type hints are not checked by Mypy at all with this configuration. This allows adding type hints just only to select sections of the code base. It is still of course possible to gradually add typing overall and increase Mypy's strictness if desired.
See Using mypy with an existing codebase for more information.