Live data from Hacker News

Free-threaded CPython is ready to experiment with

labs.quansight.org

221–230 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#221

Earlier quoted context omitted.

[flagged]

They’re probably downvoting you because you’ve posted like the laziest trope comment there is. lol Python slow everyone is paid to hide the truth amirite

[flagged]

Re: Free-threaded CPython is ready to experiment with

#222
post #6

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

Python 3.12 introduces a little bit of JIT. Also, there is always pypy. For efficient dependency management, there is now rye and UV. So maybe you can check all those boxes?

Rye is pretty alpha, uv is young, too, and they are not part of "core" Python, not under the Python Foundation umbrella (like e.g. mypy is).

So there's plenty of well-founded hope, but the boxes are still not checked.

Re: Free-threaded CPython is ready to experiment with

#223

Earlier quoted context omitted.

I feel like most things that will benefit from moving to multiple cores for performance should probably not be written in Python. OTH "most" is not "all" so it's gonna be awesome for some.

I personally optimize more for development time and overall productivity in creating and refactoring, adding new features, etc. I'm just so much faster using Python than anything else, it's not even close. There is such an incredible world of great libraries easily available on pip for one thing. Also, I've found that ChatGPT/Claude3.5 are much, much smarter and better at Python than they are at C++ or Rust. I can us…

Kind of sounds like you are optimizing for convenience :)

Re: Free-threaded CPython is ready to experiment with

#224

Earlier quoted context omitted.

[flagged]

It's very unpopular to mention Perl, but I did many cool things with it back in the day, and it still holds a special place for me. Perl taught me the power of regex--it's really first class in Perl. I still have some Perl code in production today. But to be fair, it is really easy to write spaghetti in Perl if you don't know what you're doing.

don't worry about unpopularity, bro. worry about being true. the rest will take care of itself. if not, you are in the wrong company, forum, or place, and better to work on getting out of there.

Re: Free-threaded CPython is ready to experiment with

#225

Earlier quoted context omitted.

One day your ISP emails you that they increased your upload and download speeds. Sweet, right? Same here with Python.

[flagged]

https://news.ycombinator.com/item?id=40951145

Re: Free-threaded CPython is ready to experiment with

#226

Earlier quoted context omitted.

What are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.

It’s hard to say because we’ve come up with a lot of ways to work around the fact that threaded Python has always sucked. Why? Because there’d been no demand to improve it. Why? Because no one used it. Why? Because it sucked. I’m looking forward to seeing how people use a Python that can be meaningfully threaded. While It may take a bit to built momentum, I suspect that in a few years there’ll be obvious use cases th…

Maybe a place to look for obvious use cases is in other languages. JS doesn't have threads, but Swift does. The reason I can't think of one is, free threads are most useful for full parallelism that isn't "embarrassingly parallel," otherwise IPC does fine.

So far, I've rarely seen that. Best example I deal with was a networking project with lots of communication across threads, and that one was too performance-sensitive to even use C++, let alone Py. Other things I can think of are OS programming which again has to be C or Rust.

Re: Free-threaded CPython is ready to experiment with

#227

Earlier quoted context omitted.

Bashing Python in Python development thread is not tactful.

it may not be tactful but it sure is factful (even if that last word is ungrammatical, at least the sentence is poetical). he he he. jfc. guido knows ;), this thread is getting weirder and weirder, creepier and creepier. are you literally implying that I should lie about known facts about python slowness? "tactful" my foot. then I guess the creators of PyPy and Unladen Swallow (the latter project was by Google) were/…

if Google wanted a performance increase of 5x over the then existing python, I guess we can safely say that Python was slow, amirite. and yes, I know the version number mentioned, and what it is today.

Re: Free-threaded CPython is ready to experiment with

#228
post #220

Earlier quoted context omitted.

[flagged]

You might be getting downvoted because many people know Python is among the slower dynamic languages, and there are other reasons to use it. Speaking for myself, the reasons that make me reach for Python for some projects are the speed of development, large ecosystem of libraries, large developer pool, and pretty good tooling/IDE support.

then it would be much preferable if they said so explicitly, although both of those are points I already know well. both are common knowledge, not just the first, i e. the slowness. the productivity and other benefits are common knowledge too.

downvoting is such a fucking dumb way of disagreeing. how does one know whether the downvote is because a person disapproves of or dislikes what one said or because they think what one said is wrong. no way to know. amirite? :)

Re: Free-threaded CPython is ready to experiment with

#229
post #113

Earlier quoted context omitted.

Basically true in JS too. You're not supposed to do blocking calls in async code. You also can't "await" an async call inside a non-async func, though you could fire-and-forget it. Right, but how often does a Python program have complex shared state across threads, rather than some simple fan-out-fan-in, and also need to take advantage of multiple cores?

The primary thing that tripped me up about async/await, specifically only in Python, is that the called function does not begin running until you await it. Before that moment, it's just an unstarted generator. To make background jobs, I've used the class-based version to start a thread, then the magic method that's called on await simply joins the thread. Which is a lot of boilerplate to get a little closer to how as…

There is also https://docs.python.org/3/library/asyncio-task.html#eager-ta... if you want your task to start on creation.

Re: Free-threaded CPython is ready to experiment with

#230

Earlier quoted context omitted.

I often reach for python multiprocessing for code that will run $singleDigit number of times but is annoyingly slow when run sequentially. I could never justify the additional development time for using a more performant language, but I can easily justify spending 5-10 minutes making the embarrassingly parallel stuff execute in parallel.

I've generally been able to deal with embarassing parallelism by just chopping up the input and running multiple processes with GNU Parallel. I haven't needed the multiprocessing module or free threading so far. I believe CPython still relies on various bytecodes to run atomically, which you get automatically with the GIL present. So I wonder if hard-to-reproduce concurrency bugs will keep surfacing in the free-threa…

Async seems fine? What's wrong with it?
Post reply on HN