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

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

271–280 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#271

Post by pansa2 »

anwlamp wrote: post #270
wokwokwok wrote: post #238

Earlier quoted context omitted.

> there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects This just isn’t true. This does not improve single threaded performance (it’s worse) and concurrent programming is already available. This will make it less annoying to do concurrent processing. It also makes everything slower (arguable where that ends up, curr…

Yes, good summary. My prediction is that free-threading will be the default at some point because one of the corporations that usurped Python-dev wants it. The rest of us can live with arcane threading bugs and yet another split ecosystem. As I understand it, if a single C-extension opts for the GIL, the GIL will be enabled. Of course the invitation to experiment is meaningless. CPython is run by corporations, many e…

> one of the corporations that usurped Python-dev

Man, that phrase perfectly encapsulates so much of Python’s evolution over the last ~10 years.

Re: Free-threaded CPython is ready to experiment with

#272

Post by zo1 »

arp242 wrote: post #80
simonw wrote: post #67

Earlier quoted context omitted.

"I don't want a bunch of venvs" That's your problem right there. Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements. If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck. Have you…

Managing a farm of virtualenvs and mucking about with my PATH doesn't address the user-installable problem at all. And it seems there's a new tool to try every few months that really will fix all problems this time. And maybe if you're a Python developer working on the code every day that's all brilliant. But most people aren't Python developers, and I just want to try that "Show HN" project or whatnot. Give me a sin…

I could say the exact same stuff about NodeJs, c++, go, rust, php, etc. All of these are easy to use and debug and "install easily" when you know them and use them regularly, and the opposite if you're new. Doubly-so if you personally don't like that language or have some personal pet peeve about it's choices.

Guys let's not pretend like this is somehow unique to python. It's only until about a few years ago that it was incredibly difficult to install and use npm on windows. Arguably the language ecosystem with the most cumulative hipster-dev hours thrown at it, and it still was a horrible "dev experience".

Re: Free-threaded CPython is ready to experiment with

#273

Post by blumomo »

vegabook wrote: post #236

Clearly the Python 2 to 3 war was so traumatising (and so badly handled) that the core Python team is too scared to do the obvious thing, and call this Python 4. This is a big fundamental and (in many cases breaking) change, even if it's "optional".

Did Python as the language change which justified that version bump?

Re: Free-threaded CPython is ready to experiment with

#274

Post by pletnes »

__MatrixMan__ wrote: post #83
jolux wrote: post #9

Earlier quoted context omitted.

The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.

Python's dependency management sucks because they're audacious enough to attempt packaging non-python dependencies. People always bring Maven up as a system that got it right, but Maven only does JVM things. I think the real solution here is to just only use python dependency management for python things and to use something like nix for everything else.

This is what we used to have and it was much worse. Source: lived that life 10-15 y ago.

Re: Free-threaded CPython is ready to experiment with

#275

Post by VeejayRampay »

noisy_boy wrote: post #149
VeejayRampay wrote: post #35

Earlier quoted context omitted.

the efficient dependency management is coming, the good people of astral will take care of that with the uv-backed version of rye (initially created by Armin Ronacher with inspirations from Cargo), I'm really confident it'll be good like ruff and uv were good

rye's habit of insisting on creating a .venv per project is a deal-breaker. I don't want .venvs spread all over my projects eating into space (made worse by the ml/LLM related mega packages). It should atleast respect activated venvs.

well that's good for you, but you're in the minority and rye will end up being a standard anyway, just like uv and ruff, because they're just so much better than the alternatives

Re: Free-threaded CPython is ready to experiment with

#276

Post by pletnes »

Galanwe wrote: post #22
jolux wrote: post #9

Earlier quoted context omitted.

The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.

Not sure this is still a valid critic of Python in 2024. Between pip, poetry and pyproject.toml, things are now quite good IMHO.

This is the truth right here. The issues are with people using (not officially) deprecated tools and workflows, plus various half baked scripts that solved some narrow use cases.

Re: Free-threaded CPython is ready to experiment with

#277

Post by zarzavat »

whoiscroberts wrote: post #173
nine_k wrote: post #6

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

Optional static typing, not really. Those type hints are not used at runtime for performance. Type hint a var as a string then set it to an init, that code still gonna try to execute.

> Those type hints are not used at runtime for performance.

This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run.

> Type hint a var as a string then set it to an int, that code still gonna try to execute.

But it will fail type checking, no?

Re: Free-threaded CPython is ready to experiment with

#279

Post by kallapy »

simonw wrote: post #67
arp242 wrote: post #56

Earlier quoted context omitted.

I guess that depends from your perspective. I'm not a Python developer, but like many people I do want to run Python programs from time to time. I don't really know Rust, or Cargo, but I never have trouble building any Rust program: "cargo build [--release]" is all I need to know. Easy. Even many C programs are actually quite easy: "./configure", "make", and optionally "make install". "./configure" has a nice "--help…

"I don't want a bunch of venvs" That's your problem right there. Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements. If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck. Have you…

I reject the virtual environments and have no issues. On an untrusted machine (see e.g. the recent token leak):

  /a/bin/python3 -m pip install foo
  /b/bin/python3 -m pip install bar
The whole venv thing is overblown but a fertile source for blogs and discussions. If C-extensions link to installed libraries in site-packages, of course they should use RPATH.

Re: Free-threaded CPython is ready to experiment with

#280

Post by pengaru »

pansa2 wrote: post #180
jeremycarter wrote: post #179

Earlier quoted context omitted.

Takes what crown? Python is horrifically slow even single threaded. It's by far the slowest and most energy inefficient of the major choices available today.

Popularity

javascript has entered the chat
Post reply on HN