You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LibCST would be a better fit for applying changes to the code, like the suggested types from #358. Currently, we have a mechanism that can replace an AST node and decompile it with ast-decompiler, but that's fragile and doesn't preserve comments.
The obvious option would be to use LibCST instead of ast.parse for the whole type checker. However, I'm worried that that will kill performance: running https://github.com/JelleZijlstra/autotyping on our codebase is noticeably slower than running pyanalyze, and pyanalyze has to do a lot more work itself in addition to parsing and running visitors.
Possible approaches:
Only when we try to apply a suggestion, use libcst to parse the file and change it.
Generate a json file with suggestions that can then be picked up by a libcst codemod and applied. I'd probably use autotyping for this.
Either way, we'd use the line and column number to match up ast and libcst nodes.
The text was updated successfully, but these errors were encountered:
LibCST would be a better fit for applying changes to the code, like the suggested types from #358. Currently, we have a mechanism that can replace an AST node and decompile it with ast-decompiler, but that's fragile and doesn't preserve comments.
The obvious option would be to use LibCST instead of ast.parse for the whole type checker. However, I'm worried that that will kill performance: running https://github.com/JelleZijlstra/autotyping on our codebase is noticeably slower than running pyanalyze, and pyanalyze has to do a lot more work itself in addition to parsing and running visitors.
Possible approaches:
Either way, we'd use the line and column number to match up ast and libcst nodes.
The text was updated successfully, but these errors were encountered: