TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Ruff Formatter: A fast, Black-compatible Python formatter

56 点作者 CathalMullan超过 1 年前

3 条评论

veqq超过 1 年前
The difference in tooling stories of DIY ecosystems like Python vs. batteries included ecosystems like Go is fascinating.<p>I&#x27;ve rarely thought of formatting in Go (occasionally wishing it would allow 1 line if statements). But this forgoes many possible optimizations. We don&#x27;t get fun stories of 30x improvements! (And Go could be optimized a lot, the main compiler implementation foregoes most possible optimizations because the team prioritizes keeping it simple to enable long term refactoring.)<p>But then in Python I remember tab or space battles, in C you have endless formatting battles which they call coding styles etc. etc. I&#x27;ve never worked professionally in it but it seems like you get people using random build tools... Which are constantly improving! Yet the constant churn horrifies me, seems like it would take up a lot of mental space. Is that true in practice?<p>LISP (well, Scheme (well, Racket)) is a weird middle ground. Formatting e.g. seems like a solved problem, built into the IDEs with similar behavior since IDK when (I&#x27;ve never thought about it.) Overall, you sort of create tooling while programming. In Common Lisp, substantial tooling is also built into the professional IDEs. The compilers also do quite a lot.
评论 #38007045 未加载
评论 #38009188 未加载
wodenokoto超过 1 年前
I really don’t like how black formats list that ends with a comma differently from lists that don’t. I hope this either didn’t make it to ruff or can be turned off.<p>Either way, it looks like an interesting development!
评论 #38009277 未加载
freediver超过 1 年前
Impressive tool, amazing speed. What is the business model behind the company?