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

81–90 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#81

Post by hot_gril »

simonw wrote: post #79
nine_k wrote: post #76

Earlier quoted context omitted.

I used to think like that until I tried. There are areas where typing is more important: public interfaces. You don't have to make every piece of your program well-typed. But signatures of your public functions / methods matter a lot, and from them types of many internal things can be inferred. If your code has a well-typed interface, it's pleasant to work with. If interfaces of the libraries you use are well-typed,…

This was the thing that started to bring me around to optional typing as well. It makes the most sense to me as a form of documentation - it's really useful to know what types are expected (and returned) by a Python function! If that's baked into the code itself, your text editor can show inline information - which saves you from having to go and look at the documentation yourself. I've started trying to add types to…

This is what made me give it a shot in TS, but the problem is your types at interface boundaries tend to be annoyingly complex. The other problem is any project with optional types soon becomes a project with required types everywhere.

There might be more merit in widely-used public libraries, though. I don't make those.

Re: Free-threaded CPython is ready to experiment with

#82

Post by guhidalg »

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…

Normal users who just want to run some code shouldn't need to learn why they need a venv or any of its alternatives. Normal users just want to download a package and run some code without having to think about interfering with other packages. Many programming languages package managers give them that UX and you can't blame them for expecting that from Python. The added step of having to think about venvs with Python is not good. It is a non-trivial system that every single Python user is forced to learn, understand, and the continually remember every time they switch from one project to another.

Re: Free-threaded CPython is ready to experiment with

#83

Post by __MatrixMan__ »

jolux wrote: post #9
janice1999 wrote: post #7

Earlier quoted context omitted.

Not sure what this list means, there are successful languages without these feature. Also Python 3.13 [1] has an optional JIT [2], disabled by default. [1] https://docs.python.org/3.13/whatsnew/3.13.html [2] https://peps.python.org/pep-0744/

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.

Re: Free-threaded CPython is ready to experiment with

#84

Post by hot_gril »

BugsJustFindMe wrote: post #73
stavros wrote: post #69

Earlier quoted context omitted.

I feel you. I know asyncio is "the future", but I usually just want to write a background task, and really hate all the gymnastics I have to do with the color of my functions.

I feel like "asyncio is the future" was invented by the same people who think it's totally normal to switch to a new javascript web framework every 6 months.

JS had an event loop since the start. It's an old concept that Python seems to have lifted, as did Rust. I used Python for a decade and never really liked the way it did threads.

Re: Free-threaded CPython is ready to experiment with

#85

Post by stavros »

teaearlgraycold wrote: post #70
stavros wrote: post #68

Earlier quoted context omitted.

Well, I'm not looking forward to the day when I upgrade my Python and suddenly I have to debug a ton of fun race conditions.

It's kept behind a flag. Hopefully will be forever.

Oh, very interesting, that's a great solution then.

Re: Free-threaded CPython is ready to experiment with

#86

Post by vhcr »

arp242 wrote: post #56
Galanwe wrote: post #22

Earlier quoted context omitted.

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

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…

Do you have a problem with Node.js too because it creates a node_modules folder, or is the problem that it is not handled automatically?

Re: Free-threaded CPython is ready to experiment with

#87

Post by stavros »

BugsJustFindMe wrote: post #73
stavros wrote: post #69

Earlier quoted context omitted.

I feel you. I know asyncio is "the future", but I usually just want to write a background task, and really hate all the gymnastics I have to do with the color of my functions.

I feel like "asyncio is the future" was invented by the same people who think it's totally normal to switch to a new javascript web framework every 6 months.

I agree, I find Go's way much easier to reason about. It's all just functions.

Re: Free-threaded CPython is ready to experiment with

#88

Post by hot_gril »

andrewaylett wrote: post #58
GTP wrote: post #46

Earlier quoted context omitted.

Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a f…

It calls x.__add__(y). Python types are strictly specified, but also dynamic. You don't need static types in order to have strict types, and indeed just because you've got static types (in TS, for example) doesn't mean you have strict types. A Python string is always a string, nothing is going to magically turn it into a number just because it's a string representation of a number. The same (sadly) can't be said of J…

Yeah and even with static typing, a string can be many things. Some people even wrap their strings into singleton structs to avoid something like sending a customerId string into a func that wants an orderId string, which I think is overkill. Same with int.

Re: Free-threaded CPython is ready to experiment with

#89

Post by stavros »

yosefk wrote: post #10
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++.

If Python's dependency management is better than anything, it's better than C++'s. Python has pip and venv. C++ has nothing (you could say less than nothing since you also have ample opportunity for inconsistent build due to mismatching #defines as well as using the wrong binaries for your .h files and nothing remotely like type-safe linkage to mitigate human error. It also has an infinite number of build systems whe…

That was the entire point, that C++ is the absolute worst.

Re: Free-threaded CPython is ready to experiment with

#90

Post by vhcr »

GTP wrote: post #46
hot_gril wrote: post #40

Earlier quoted context omitted.

It is properly typed: it has dynamic types :)

Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a f…

In theory it's nice that the compiler would catch those kinds of problems, but in practice it doesn't matters.
Post reply on HN