I'm happy with Ruff[0], it's very fast. [0] -- https://github.com/astral-sh/ruff
[dead]
Writing and linting Python at scale
41–50 of 160 posts
Re: Writing and linting Python at scale
#42I'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…
This isn’t really accurate in my experience. I’ve been using it on several projects large and small for some time now and can only recall one time autofix introduced an issue of any sort and that was many versions ago. It will also handle cascading fixes just fine.
Re: Writing and linting Python at scale
#43But but but HN told me that python is only good for small scale and prototypes, the engineers at meta are wrong
I've been writing in Python for over ten years, in different roles, for wildly different projects (research, infra, Web, testing, education). I'm yet to find anything Python was good for. On engineering merits alone Python isn't best for anything, nor is it best for combinations of things. It's silly to think that any tool that works with Python does so because Python was the best language for the job, and they only…
Python is always the second-best language for the job. Which makes it a great language to know.
Re: Writing and linting Python at scale
#44Earlier quoted context omitted.
Python not only has types but it's type system is superior to typeScript. Get this python has sum types and exhaustive pattern matching exactly like rust or haskell. The only problem with python are the libraries are sometimes written with tricks that make static typing ineffective. Other than that it is really really good at scale. Better API then typescript imo which is really it's main competitor. edit: (rate limi…
> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at others. Many functions can't be accurately typed (try, for example, to make a well-typed function that concatenates two arbitrary fixed-size tuples), and as far as I know generic type transformations can't be implemented (random example "this type takes a Dict[str,…
For the tuple example:
from typing import TypeVar
T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W')
def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]:
return a + b
from typing import Any, Callable
Transformer = Callable[[dict[str, Any]], dict[Callable, Any]]
Re: Writing and linting Python at scale
#45Re: Writing and linting Python at scale
#46Earlier quoted context omitted.
Python not only has types but it's type system is superior to typeScript. Get this python has sum types and exhaustive pattern matching exactly like rust or haskell. The only problem with python are the libraries are sometimes written with tricks that make static typing ineffective. Other than that it is really really good at scale. Better API then typescript imo which is really it's main competitor. edit: (rate limi…
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()}]}Re: Writing and linting Python at scale
#47Earlier quoted context omitted.
Python not only has types but it's type system is superior to typeScript. Get this python has sum types and exhaustive pattern matching exactly like rust or haskell. The only problem with python are the libraries are sometimes written with tricks that make static typing ineffective. Other than that it is really really good at scale. Better API then typescript imo which is really it's main competitor. edit: (rate limi…
Surprise: all languages have types. Superior to TypeScript is neither a high bar, nor is this any kind of objective metric. I don't know why sum types are a blessing, also I don't know why pattern matching makes anything better. I can name a lot of problems with Python, and I'm sure that libraries isn't the only one. For example, for no reason, Python has multiple unrelated mechanisms to manage program state (object,…
Why is pathlib bad?
Edit: I'm asking because pathlib is as good as a Python lib could be for me. Path manipulations are extremely clear and always safe. What more do you need?
Re: Writing and linting Python at scale
#48Earlier quoted context omitted.
In the C#/.NET world this is the standard and it works very well. It definitely increases productivity to not have to double check each and every instance of violating a lint error, as you can just have the fix applied to an entire project without having to worry to much.
> 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 more advanced problems which where not caught by automatic analysis. It's not perfect, but it reduces useless churn.
This also holds true for rider and vs with resharper.
Re: Writing and linting Python at scale
#49Earlier quoted context omitted.
> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at others. Many functions can't be accurately typed (try, for example, to make a well-typed function that concatenates two arbitrary fixed-size tuples), and as far as I know generic type transformations can't be implemented (random example "this type takes a Dict[str,…
For the tuple example: from typing import TypeVar T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W') def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]: return a + b For the generic type transformation example, I'm not sure what you mean: from typing import Any, Callable Transformer = Callable[[dict[str, Any]], dict[Callable, Any]] This seems to match your question but it's really w…
Your tuple example only works if both tuples have two elements. I specifically mentioned arbitrary fixed-size tuples (as in, tuples with an arbitrary non-variable length).
Your generic type transformation example also doesn't come close to what Typescript does. The resulting dict will not have known keys based on the keys of the input dict. In Typescript I can write a function that takes an object with known keys, and it returns an object with those same keys having their values mapped to a different type, with the keys still known. I threw together a quick example - just look at the type of resultA/resultB by hovering over the variables[0].
But both are great examples - they are probably the closest you can get in Python, and they are so far removed from the thing I want to represent that they are completely useless.
[0]: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA...
Re: Writing and linting Python at scale
#50(It's a podcast, not an article)
The description links to the tech article. https://engineering.fb.com/2023/08/07/developer-tools/fixit-...
Changed to that from https://engineering.fb.com/2023/11/21/production-engineering.... Thanks!
(I fixed the link in your comment btw. More at https://news.ycombinator.com/formatdoc)