Free-threaded CPython is ready to experiment with

Post by VagabundoP » Sat, Jul 13, 2024, 7:32 PM UTC

guhidalg wrote: post #82

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…

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…

Post by quietbritishjim » Sat, Jul 13, 2024, 7:53 PM UTC

viraptor wrote: post #205

Demiurge wrote: post #202

Earlier quoted context omitted.

Massive overhead of multiprocessing? How have I not noticed this for tens of years? I use coroutines and multiprocessing all the time, and saturate every core and all the IO, as needed. I use numpy, pandas, xarray, pytorch, etc. How did this terrible GIL overhead completely went unnoticed?

> I use numpy, pandas, xarray, pytorch, etc. That means your code is using python as glue and you do most of your work completely outside of cPython. That's why you don't see the impact - those libraries drop GIL when you use them, so there's much less overhead.

Post by radarsat1 » Sat, Jul 13, 2024, 8:14 PM UTC

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…

Post by cozzyd » Sat, Jul 13, 2024, 8:44 PM UTC

stavros wrote: post #259

ahartmetz wrote: post #246

Earlier quoted context omitted.

Is that because the compiler failed with "foo.h not found" or the build system said "libfoo not found"? CMake is most common and it will tell you. Worst case it's difficult to derive the package name from the name in the diagnostic. It's not great, but usually not a big deal neither IME. Typically a couple of minutes to e.g. find that required libSDL2 addon module or whatever, if there is that kind of problem at all.

Yes it is, and it's usually such a big deal for me that I just don't use that software. I don't have time to go through a loop of "what's the file name? What package is it in? Install, repeat". This is by far the worst experience I've had with any language. Python has been a breeze in comparison.

Post by andrewaylett » Sat, Jul 13, 2024, 9:08 PM UTC

GTP wrote: post #298

andrewaylett wrote: post #58

Earlier quoted context omitted.

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…

> It calls x.__add__(y) Your answer doesn't solve the problem, it just moves it: can you tell me what x. __add__(y) does?

    fn add, U>(a: T, b: U) -> T::Output { a + b }