Related and a bit recent:
Fixit 2: Meta’s auto-fixing linter for Python - https://news.ycombinator.com/item?id=37036262 - Aug 2023 (11 comments)
Writing and linting Python at scale
51–60 of 160 posts
Re: Writing and linting Python at scale
#52I'm happy with Ruff[0], it's very fast. [0] -- https://github.com/astral-sh/ruff
Unfortunately ruff is very inconsistent and has lots of differences from the flake8 plugins it tries to emulate. Lots of rules are confused by irrelevant context so that it can miss lots of things it should find when the equivalent flake8 plugin still find them. It's automatic fixing of issues will happily introduce other issues that it doesn't find until the next run. I've tried pretty hard to use it and gave up, it…
We've gone all in on Ruff for several months now, across many projects, and not noticed any of these issues.
Re: Writing and linting Python at scale
#53It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".
As someone who worked on a similar tool (https://github.com/ssbr/refex/tree/main/refex/fix/fixers, I did a bunch of the work to prep this for open-sourcing, though I think all my contributions are hidden behind the "Google-internal" anonymization), having auto-applied or auto-appliable fixers like this is super useful.
They can be auto-applied by post-commit (e.g. a generic `git fixcommit` style command that runs all the relevant lint tools and fixes them in the working copy, letting you review before push), or applied during code review (automatic comments with a "click here to apply fix" interface), both of which are nice.
Plus the same underlying tooling can be used to write more complex one-off fixes that may be used for migrations or cleanups.
Re: Writing and linting Python at scale
#54It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".
"black" for python has already done this for quite a while.
Even before that, some flake8 linting rules could automatically apply the fix, but not all of then.
Re: Writing and linting Python at scale
#55Earlier quoted context omitted.
I mean, as far as I'm concerned, everything Facebook has done has done nothing but reconfirm how unwise it is to build large-scale infrastructure on dynamic scripting languages. They have the resources to move heaven and earth to do what amounts to turning their dynamic scripting language back into static languages in everything but name, and they have the hole they've dug themselves into that justifies it. I have ne…
> dynamic scripting languages. Why keep repeating this nonsense? "Dynamic" or "scripting" aren't features of languages. When anyone says something like this, it's like talking about square chicken... (i.e. a category error). Obviously, you had some idea in your mind, and you wanted to communicate it somehow, but your readers will not know what it was unless you make an effort to analyze what you want to say and make…
> "Dynamic" or "scripting" aren't features of languages
Surely dynamic typing is a language feature? I can't imagine what else someone would refer to with "dynamic".
Re: Writing and linting Python at scale
#56Earlier quoted context omitted.
You can't even represent `Json` in Python's type system because it would require a recursive type. edit: I think this is actually a Python type annotation limitation but it's possible that's mypy, although I think in 99% of cases those are fine to conflate (I have used other Python type systems).
In VSCode (which uses PyRight/PyLance) and Python 3.10: JSONObject = None | str | int | bool | list["JSONObject"] | dict[str, "JSONObject"] # this type checks a: JSONObject = {"a": [1, 2, "7", True, {"false": None}]} # this doesn't type check b: JSONObject = {"a": [1, 2, "7", True, {"false": object()}]}
Cool, guess they finally fixed this. Must've been in the last ~1 year, give or take. Of course, it relies on quoting your types, which is... a matter of taste, I suppose.
Re: Writing and linting Python at scale
#57It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".
You don't have to trust it - just commit your changes then run the linter and inspect the diff.
Re: Writing and linting Python at scale
#58Earlier quoted context omitted.
I mean, as far as I'm concerned, everything Facebook has done has done nothing but reconfirm how unwise it is to build large-scale infrastructure on dynamic scripting languages. They have the resources to move heaven and earth to do what amounts to turning their dynamic scripting language back into static languages in everything but name, and they have the hole they've dug themselves into that justifies it. I have ne…
> dynamic scripting languages. Why keep repeating this nonsense? "Dynamic" or "scripting" aren't features of languages. When anyone says something like this, it's like talking about square chicken... (i.e. a category error). Obviously, you had some idea in your mind, and you wanted to communicate it somehow, but your readers will not know what it was unless you make an effort to analyze what you want to say and make…
Could you enlighten me as to how a type system is not part of a language?
For example, in your own words, what is the main difference between typescript and javascript?
Re: Writing and linting Python at scale
#59Earlier quoted context omitted.
> increases productivity to not have to double check each and every instance of violating a lint error, At what cosmic speed should you be pumping out code for this to be a concern? Also, in C#/.NET, where programmers predominantly use MSVS, which is an atrocious editor with MSBuild, which is an atrocious build system, both hampering productivity... Also, plenty of linter errors are actual errors that need non-trivia…
It's very useful for multiple scenarios: 1. Learning new syntax. E.g. the new switch expressions are pretty neat and better than the old switch statements. Changing and learning how to write them is super easy thanks to this feature. 2. A code base with less then good practices is vastly easier to adjust to better standards than in python. I've done both and dotnet is mostly applying suggestions and then looking for…
And VS Code too with the analyzers that come with the sdk! (or numerous others that are available as extensions e.g. Roslynator)
Re: Writing and linting Python at scale
#60Earlier quoted context omitted.
In VSCode (which uses PyRight/PyLance) and Python 3.10: JSONObject = None | str | int | bool | list["JSONObject"] | dict[str, "JSONObject"] # this type checks a: JSONObject = {"a": [1, 2, "7", True, {"false": None}]} # this doesn't type check b: JSONObject = {"a": [1, 2, "7", True, {"false": object()}]}
Cool, guess they finally fixed this. Must've been in the last ~1 year, give or take. Of course, it relies on quoting your types, which is... a matter of taste, I suppose.
Quoting types that are defined later is a wart but it's not very bad. VSCode's UI will happily handle it as if the quotes weren't there.