Typing #261
Labels
❓ help wanted
Extra attention is needed
Comments
|
Thanks for pointing it out, I actually have no enough energy to enforce type annotations for the whole codebase. Contributions are welcomed of course. |
Merged
|
for a sense of scale, here's the current output from mypy- mypy output |
|
@danieleades I suggest this project only enables And if ci has mypy after solving all errors, it would be great. |
that seems like a reasonable mypy config. i'm using something similar locally while i'm messing about. I suggest perhaps you should open a pull request to add the config file and dependencies to the repo? As for breaking down the separate tasks, so far i've just been tackling one file at a time, starting with the ones that generate the most errors. Personally, i'm not going to be able to make a lot more progress without input from @frostming. A lot of the remaining type errors stem from using objects that might be |
|
Sure, I got it. I'll check them later. Almost all codes are covered by pytest thanks to the author, so we can check sys.setprofile to what type is required for all functions, I think. I'll make PR while checking your PR. |
ghost
mentioned this issue
2 tasks
|
This isn't really working. @frostming is it possible for you to use mypy to lint new code as you add it? Is that something you'd be interested in? You're adding code at a very fast rate, and despite addressing hundreds of type errors, there's now more errors than when I started... |
|
First of all, thanks a lot @danieleades for looking into this topic. "There is no glory in prevention" and the same is true for linting and type checking, I'm afraid to say. 😉 Of course, pdm is your baby, @frostming, and working on new features is so much more attractive than introducing mypy for an extensive code base, but the long-term benefits of using mypy (or sth similar) are substantial and well worth the effort, IMHO. That's just my two cents worth. |
|
I never disregard type hints, I myself also improved the types and reduced the error number by ~100. Everyone can contribute to improving this and I am glad to review it.
Don't urge on that, many errors were introduced by a patch that applied types from an automation tool(pyannotate). Keep on the good work and we will finally get the green flag to add |
|
Apologies all! Planning to do a little more on this when I can. In the middle of a home renovation, so I'm short on free time right now! |
|
right, i've got a plan. i've added a mypy config and pre-commit hook in #427 the pre-commit hook has a small whitelist of files. over time, as type errors are stripped from files they can be added to the whitelist. This prevents type errors from being re-introduced to existing files that have been 'cleared'. Any new files should be added to this whitelist in the pull request in which they're created. Sound ok? |
|
Here is the good news: all type errors in the codebase are cleared #517 Thanks all |
|
Amazing effort. Well done |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm hoping to gradually improve the 'typing' in this library to the point where it can be linted using Mypy.
There's quite a lot to do first! This library uses a few loosely-typed data structures which lead to a lot of type errors. That will possibly involve some refactoring (or heavy use of
if not Nonechecks everywhere).I'll use this is as a parent task for various efforts to improve the typing-
The text was updated successfully, but these errors were encountered: