←back to thread

Code formatting comes to uv experimentally

(pydevtools.com)
365 points tanelpoder | 3 comments | 21 Aug 25 20:26 UTC | HN request time: 0.644s | source
Show context
thanhhaimai ◴[21 Aug 25 21:20 UTC] No.44978239[source]▶
I'd rather `ruff` being merged with `ty` instead. `uv` for me is about package / project manager. It's not about code style. The only time `uv` should edit a code file is to update its dependencies (PEP 723).

On the other hand, both `ruff` and `ty` are about code style. They both edit the code, either to format or fix typing / lint issues. They are good candidates to be merged.

replies(7): >>44978308 #>>44978351 #>>44978465 #>>44978499 #>>44978500 #>>44979712 #>>44981364 #
zahlman ◴[21 Aug 25 21:45 UTC] No.44978465[source]▶
This is the direction I expected things to go, and not something I'm especially fond of. I'll stick with UNIX-philosophy tools, thanks.
replies(5): >>44978583 #>>44979916 #>>44979956 #>>44980082 #>>44981479 #
gchamonlive ◴[22 Aug 25 00:43 UTC] No.44979916[source]▶
There is wisdom in knowing when -- and how -- to break standards. Don't know if this is the case, but I think it is. If introducing fmt powers to UV meant it had to consider tradeoffs elsewhere where it might hurt its quality somehow then maybe, but in this case UV is more like an umbrella, unifying the interface for pip, venv, builds... And now fmt. All keeping each separate domain isolated without details leaking to one another.
replies(1): >>44980206 #
zahlman ◴[22 Aug 25 01:39 UTC] No.44980206[source]▶
What do I gain from adding 'uv' to the start of each of these commands, as opposed to having them all just be separate commands?
replies(3): >>44980396 #>>44980623 #>>44980992 #
asa400 ◴[22 Aug 25 03:02 UTC] No.44980623[source]▶
Abstraction. Not having to know all the innards (or even names) of each until you want to. It's all there if you want to, but stuff like uv (or cargo, or go's toolset) greatly simplifies 3 scenarios in particular: starting a new project, joining an existing project, and learning Python for the first time.

All 3 scenarios benefit from removing the choice of build tool, package manager, venv manager, formatter, linter, etc., and saying, "here, use this and get on with your life".

replies(1): >>44982494 #
zahlman ◴[22 Aug 25 09:26 UTC] No.44982494[source]▶
How is "uv format" a better name, or more "abstract", etc. etc., than "ruff check"? Why is it easier to think of my formatter and package manager (or whatever other pieces) as being conceptually the same tool, given that they are doing clearly different, independent and unrelated things?

And why is any of this relevant to first-time Python learners? (It's already a lot to ask that they have to understand version control at the same time that they're learning specific language syntax along with the general concept of a programming language....)

replies(2): >>44984710 #>>44989762 #
1. asa400 ◴[22 Aug 25 13:52 UTC] No.44984710[source]▶
It’s an abstraction because it literally hides knowledge in service of presenting a more a more cohesive API to the human.

It requires less knowledge at the front end, which is when people are being bombarded with a ton of new things to learn.

Learners don’t have to even know what ruff is immediately. They just know that when they add “format” to the command they already know, uv, their code is formatted. At some later date when they know Python better and have more opinions, they can look into how and why that’s accomplished, but until then they can focus on learning Python.

uv isn’t a package manager only, its best thought of as a project manager, just like go or cargo. Its “one thing” is managing your Python project.

replies(1): >>44985156 #
2. zahlman ◴[22 Aug 25 14:31 UTC] No.44985156[source]▶
Would Linux similarly be better if we wrote e.g. "cu list" instead of "ls", "cu change" instead of "cd", etc.? (The "cu" stands for "coreutils", of course.) Because it seems to me like the same arguments apply. I was already thinking of uv as a "project manager" and I understand that intended scope, and even respect the undertaking. My point is that I don't believe that labeling all the tasks under that scope like this actually improves the UX.

Maybe I'm wrong about that. But I don't know that it can actually be A/B tested fairly, given network effects (people teaching each other or proselytizing to each other about the new way).

replies(1): >>44985552 #
3. woodruffw ◴[22 Aug 25 15:08 UTC] No.44985552[source]▶
I don't think Linux would be better with a `cu` prefix for coreutils, but I do think git would be worse without a `git` prefix. I think it's ultimately a question of user expectations, and I think user expectations around packaging tooling in particular have shifted towards the Go and Rust styles of providing a "namespace" tool that provides a single verb-style interface for developer actions.