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

141–150 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#141

Post by kortex »

zitterbewegung wrote: post #17
GTP wrote: post #11

Earlier quoted context omitted.

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system.…

Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.

Nope. Type annotations can be executed and accessed by the runtime. That's how things like Pydantic, msgspec, etc, do runtime type enforcement and coercion.

There are also multiple compilers (mypyc, nuitka, others I forget) which take advantage of types to compile python to machine code.

Re: Free-threaded CPython is ready to experiment with

#142

Post by dgfitz »

stavros wrote: post #89
yosefk wrote: post #10

Earlier quoted context omitted.

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.

I pip3 installed something today. It didn’t work, at all.

I then yum installed a lib and headers, it worked well.

C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

Re: Free-threaded CPython is ready to experiment with

#143

Post by NegativeK »

GTP wrote: post #11
nine_k wrote: post #6

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

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system.…

Python's typing must accommodate Python's other goal as quick scripting language. The solution is to document the optional typing system as part of the language's spec and let other tools do the checking, if a user wants to use them.

The other tools are trivially easy to set up and run (or let your IDE run for you.) As in, one command to install, one command to run. It's an elegant compromise that brings something that's sorely needed to Python, and users will spend more time loading the typing spec in their browser than they will installing the type checker.

Re: Free-threaded CPython is ready to experiment with

#144

Post by kortex »

zitterbewegung wrote: post #132
nine_k wrote: post #21

Earlier quoted context omitted.

A language server in your IDE kicks in much earlier, and is even more helpful.

I haven't used an IDE that has that but it is still just giving you a hint that there is an error and the interpreter is not throwing an error which was my point.

That's true of most compiled languages. Unless we are talking about asserts, reflection, I think type erasure, and maybe a few other concepts, language runtimes don't check types. C does not check types at runtime. You compile it and then rely on control of invariants and data flow to keep everything on rails. In python, this is tricky because everything is behind at least one layer of indirection, and thus virtually everything is mutable, so it's hard to enforce total control of all data structures. But you can get really close with modern tooling.

Re: Free-threaded CPython is ready to experiment with

#145

Post by stavros »

dgfitz wrote: post #142
stavros wrote: post #89

Earlier quoted context omitted.

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

I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

If I had a penny for every time I gave up on compiling C++ software because there's no way to know what dependencies it needs, I'd be a millionaire. Python at least lists them.

Re: Free-threaded CPython is ready to experiment with

#146

Post by dagenix »

stavros wrote: post #133
dagenix wrote: post #131

Earlier quoted context omitted.

Are you writing an extension or Python code? If you are writing Python code, the GIL can already be dropped at pretty much any point and there isn't much way of controlling when. Iirc, this includes in the middle of things like +=. There are some operations that Python defines as atomic, but, as I recall, there aren't all that many. In what way is the GIL preventing races for your use case?

I mean that, if the GIL didn't prevent races, it would be trivially removable. Races that are already there in people's Python code have probably been debugged (or at least they are tolerated), so there are some races that will happen when the GIL is removed, and they will be a surprise.

The GIL prevents the corruption of Pythons internal structures. It's hard to remove because:

1. Lots of extensions, which can control when they release the GIL unlike regular Python code, depend on it 2. Removing the GIL requires some sort of other mechanism to protect internal Python stuff 3. But for a long time, such a mechanism was resisted by th Python team because all attempts to remove the GIL either made single threaded code slower or were considered too complicated.

But, as far as I understand, the GIL does somewhere between nothing and very little to prevent races in pure Python code. And, my rough understanding, is that removing the GIL isn't expected to really impact pure Python code.

Re: Free-threaded CPython is ready to experiment with

#147

Post by stavros »

dagenix wrote: post #146
stavros wrote: post #133

Earlier quoted context omitted.

I mean that, if the GIL didn't prevent races, it would be trivially removable. Races that are already there in people's Python code have probably been debugged (or at least they are tolerated), so there are some races that will happen when the GIL is removed, and they will be a surprise.

The GIL prevents the corruption of Pythons internal structures. It's hard to remove because: 1. Lots of extensions, which can control when they release the GIL unlike regular Python code, depend on it 2. Removing the GIL requires some sort of other mechanism to protect internal Python stuff 3. But for a long time, such a mechanism was resisted by th Python team because all attempts to remove the GIL either made singl…

Hmm, that's interesting, thank you. I didn't realize extensions can control the GIL.

Re: Free-threaded CPython is ready to experiment with

#148

Post by kortex »

VeejayRampay wrote: post #37
GTP wrote: post #11

Earlier quoted context omitted.

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system.…

python will never be "properly typed" what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is

s/will never be/already is/g

https://github.com/mypyc/mypyc

You can compile python to c. Right now. Compatibility with extensions still needs a bit of work. But you can write extremely strict python.

That's without getting into things like cython.

Re: Free-threaded CPython is ready to experiment with

#149

Post by noisy_boy »

VeejayRampay wrote: post #35
nine_k wrote: post #6

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

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.

Re: Free-threaded CPython is ready to experiment with

#150

Post by stavros »

pdonis wrote: post #130
stavros wrote: post #118

Earlier quoted context omitted.

Not when there's a global interpreter lock.

The GIL does not prevent race conditions in your Python code. It only prevents race conditions in internal data structures inside the interpreter and in atomic operations, i.e., operations that take a single Python bytecode. But many things that appear atomic in Python code take more than one Python bytecode. The GIL gives you no protection if you do such operations in multiple threads on the same object.

I answered in a sibling reply: https://news.ycombinator.com/item?id=40950798
Post reply on HN