Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astral

astral.sh

Post reply on HN
Print view View original

211–220 of 248 posts

Re: Astral

#211

Post by senko »

zamnos wrote: post #183
senko wrote: post #54

Earlier quoted context omitted.

Indeed. I do hope they'll expose Ruff as a Python module / API in the future. I'm currently using Black to format Python code that's in-memory (never gets written out to disk). With Black (as an imported Py module), it's just a matter of passing in a string and getting one back. With Ruff as it is now, I'd have to write that out to disk, spawn Ruff process, then read the formatted file back in. Do that for many files…

Why doesn't ruff reading/writing from stdin/out, combined with passing the data in with python subprocess.run and os.pipe work here? cat bad.py | ruff check --fix --stdin-filename stdin.py - > good.py Substituting bad.py and good.py for in-memory os.pipe objects for your data. This still involves spawning a subprocess, which can add up, but you're not having to read/write to disk at least.

It does work. The tradeoff is:

* run ruff command many times (with different input file each time) * write all the files to "disk" (tempfs actually so it doesn't involve disk access) and run ruff once

Currently with black I avoid that by importing it as a module once so I get the benefits of both (and is simple to boot).

In other comments here I've read that a person heavily involved in Python-Rust interop is also part of the team, so there's hope they'll expose ruff as a module too and magically whisk my dilemma away :-)

Re: Astral

#212

Post by kstrauser »

mixmastamyk wrote: post #187
kstrauser wrote: post #39

Earlier quoted context omitted.

I disagree about the speed. I don't have a problem with pyflake, but running `time ruff -s .` in a project with 1,236 Python files took 78ms. At that speed, it could re-check the file I'm working on in an editor after every keystroke with no noticeable latency. It's not just a little bit faster. It's freakishly, ridiculously, gone-plaid faster. Edit: for comparison, flake8 took 8.19s and found approximately the same…

Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.

That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.

Re: Astral

#213

Post by was_a_dev »

throwaway2137 wrote: post #112

Yet another case of Python developers getting a basic utility which any other language had available for years and being amazed at something which is an industry standard literally anywhere else. Linter taking multiple seconds is not a problem which occurs in any other popular language. It really boggles my mind why is this lang so popular. Once you write something a little more involved than an utility script or jup…

> It really boggles my mind why is this lang so popular.

You are thinking like a software engineer, understandably

If you looks at STEM research fields Python is a solid tool for the fact it is a utlility/scripting tool. All the issues you listed rarely occur in this instance.

Most of the Python I write has a very limited lifetime. Typically shorted than the development time

There are indeed better Python alternatives, but very few use them in comparison

Re: Astral

#214

Post by ki_ »

korijn wrote: post #110

If your codebase is as large as cpython's, I think the benefits are clear. But most projects aren't actually this big right? Flake8 runs less than a second on even my biggest projects. Is linting such a bottleneck in people's workflows? Why bother shaving a couple seconds off a linter when your test suite and Dockerfiles take minutes to complete? I don't really see why I should care about ruff.

If both run under 500ms. I guess it's your choice. Just pick the one that's most productive for you. If flake8 takes longer than 1 second, i'd replace it with ruff. 1 second is a really really long time for a linter, even if your codebase is 1 million lines of code.

Re: Astral

#215

Post by benjaminwootton »

throwaway2137 wrote: post #112

Yet another case of Python developers getting a basic utility which any other language had available for years and being amazed at something which is an industry standard literally anywhere else. Linter taking multiple seconds is not a problem which occurs in any other popular language. It really boggles my mind why is this lang so popular. Once you write something a little more involved than an utility script or jup…

I agree on the venv, 'which python', and packages and I would add Python V2/V3. I work on a few Macbooks and have to occasionally return to Python. It's constant firefighting on environments.

Re: Astral

#216

Post by varjag »

ehsankia wrote: post #136
throwaway2137 wrote: post #112

Yet another case of Python developers getting a basic utility which any other language had available for years and being amazed at something which is an industry standard literally anywhere else. Linter taking multiple seconds is not a problem which occurs in any other popular language. It really boggles my mind why is this lang so popular. Once you write something a little more involved than an utility script or jup…

Maybe tooling for other languages are faster because the dev has to spend a lot more time specifying a lot more things / are a lot more verbose. The reason tooling on Python is slow is exactly why people love it, because it's lightweight, easy to quickly whip up a script. Take a one line hello world vs having to create an entire project and 10 lines in C#. Not having to type annotate every tiny thing is also great. Y…

The reason tooling in on Python is slow is because the language implementation is slow. We get that you love the language but it does not change that the execution is objectively poorly done.

Re: Astral

#218

Post by jeffparsons »

robocat wrote: post #210
jeffparsons wrote: post #201

Earlier quoted context omitted.

Is it actually reasonable to expect compiler toolchains to work on old or underpowered hardware? Or is the real problem that cross-compilation is still a special case, rather than being the only way compilers work? If it wasn't still normal to depend on your target environment being the same as your build host, would anyone really want to do serious development work directly on their RPi/Gameboy/watch/whatever, just…

I am wildly guessing that Theo’s beef is more that rust uses a lot of memory (paraphrase: 640kb should be enough for anybody). OpenBSD does integration builds on a variety of different systems, and maybe Theo noticed the OpenBSD/386 build failing due to lack of necessary memory?

That seems a reasonable guess, but it brings me straight back to wondering why such a diversity of build environments is necessary or useful. And my wild guess is that it's mostly because cross compilation is still a second class citizen in most languages today. Though I guess it could be a kind of cultural expectation that you should be able to compile the whole OS on the hardware you're running it on.

Re: Astral

#219

Post by globular-toast »

throwaway2137 wrote: post #112

Yet another case of Python developers getting a basic utility which any other language had available for years and being amazed at something which is an industry standard literally anywhere else. Linter taking multiple seconds is not a problem which occurs in any other popular language. It really boggles my mind why is this lang so popular. Once you write something a little more involved than an utility script or jup…

I think the main problem for you is that Python is heavily rooted in Unix and, more specifically, GNU/Linux and free software. Also, it has history. Python has been in use since the early 90s. C# is a Java knockoff that appeared almost a decade later.

The intersection of people who enjoy both C# and Python is very small. I too have worked a soul-sucking job in finance and use of languages like Java and C# was a big part of what I didn't like.

It seems there are two ways to react to the "I don't get it" situation:

1. Other people must be wrong in the head to like this,

2. I don't have the knowledge and/or experience to understand why other people like this.

In life I find it's generally better to give the benefit of the doubt and take the second path. But you may still conclude it's the first after all. All I can say is I'm grateful there are others who are wrong in the head like me and prefer Python for whatever reason.

Re: Astral

#220

Post by ohgodplsno »

toyg wrote: post #109
akprasad wrote: post #5

I love Ruff and I'm glad that Charlie and the rest of the team are able to work on such tools full-time. I'm also happy to see that the author of Maturin (Rust+Python interop) is involved, as Maturin is a fantastic project with great ease-of-use. For those who aren't familiar, Ruff is a very fast Python linter that supersedes a variety of tools like isort, flake8, and perhaps eventually Black [1]. My understanding is…

I actually cursed Maturin a few years ago, as it refused to compile on OpenBSD and hence broke some lib I planned to use. Python is becoming a bit too reliant on Rust. Rust is good but, in term of portability, is just not as mature as C. If your lib relies on Rust, please please please test it on something beyond Linux and Mac.

>If your lib relies on Rust, please please please test it on something beyond Linux and Mac.

No, thank you, I'll just add Windows. Your choice to use platforms that nobody else does save for a few specialists does not constitute a need on my part to support your favorite. In the same way that if I package for Debian, Ubuntu and RHEL, it's your problem that it's not on Arch or unsupported by your custom Hannah Montana Linux. Feel free to submit PRs though.

Post reply on HN