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

State of Python 3.13 performance: Free-threading

codspeed.io

Post reply on HN
Print view View original

161–170 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#161

Post by LtWorf »

dataflow wrote: post #84
andai wrote: post #24

Earlier quoted context omitted.

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

> Python 2 code running on Python 3 by just changing print to print(). This was very much the opposite of my experience. Consider yourself lucky.

Maybe his application was an hello world!

Re: State of Python 3.13 performance: Free-threading

#162

Post by noitpmeder »

dagw wrote: post #121
salomonk_mur wrote: post #102

Earlier quoted context omitted.

What APIs were broken? They couldn't be in the standard library. If the dependency was in external modules and you didn't have pinned versions, then it is to be expected (in almost any active language) that some APIs will break.

They couldn't be in the standard library. Why not? Python does make breaking changes to the standard library when going from 3.X to 3.X+1 quite regularly.

Only usually after YEARS of deprecation warnings

Re: State of Python 3.13 performance: Free-threading

#163

Post by notatallshaw »

jghag wrote: post #123
notatallshaw wrote: post #70

Earlier quoted context omitted.

You seem to be conflating problems and different groups of people that aren't directly related. To clarify some different groups: * The faster-cpython project, headed by Guido and his team at Microsoft, is continuing fine, most of the low hanging fruit was accomplished by 3.11, further improvements were moved to medium term goals and they were delayed further by the free threaded project which broke assumptions that…

Thanks for the party line, backed by the usual flaggers. This is how Python maintains its market share and popularity. Google though does not seem too impressed by Python any longer. Others will follow.

> Thanks for the party line, backed by the usual flaggers

The previous post was wildly conflating different things, I think is a real disservice to the actual events that happened.

I think there are systemic issues with the current structure of community governance, but having the events which show that conflated with completely unrelated work makes it more difficult to address these issues, as now there is misinformation floating around and criticism can be dismissed as being uninformed.

Re: State of Python 3.13 performance: Free-threading

#164

Post by d0mine »

roelschroeven wrote: post #155
d0mine wrote: post #79

Earlier quoted context omitted.

At least bugfix versions could have kept Enum behavior the same. Postponing breaking changes until the next minor version. Some Enum features work differently (incompatible) in Python 3.11.x versions.

> Some Enum features work differently (incompatible) in Python 3.11.x versions. I know that Python 3.11 added some things, like StrEnum; those obviously won't work on older Python versions. But I'm not aware of things that work in a certain Python 3 version but don't work in newer ones. You're even talking about incompatibilities between different 3.11.x versions? Can you give some more detail on that?

Yes, the issue is the change in behavior in a bugfix version. I don't remember the exact details.

Re: State of Python 3.13 performance: Free-threading

#165

Post by ivoflipse »

BerislavLopac wrote: post #144
klysm wrote: post #31

Earlier quoted context omitted.

So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.

Yes and no. There are different types of dependencies, and there are different rules for them, but here's an overview of the best practices: 1. For applications, scripts and services (i.e. "executable code"), during development, pin your direct dependencies; ideally to the current major or minor version, depending how much you trust their their authors to follow SemVer. Also make sure you regularly update and retest…

I reckon you're aware of it, but they're actively discussing a lock file format PEP and I'm quite hopeful this time it will actually get accepted

https://discuss.python.org/t/pep-751-now-with-graphs/69721

Re: State of Python 3.13 performance: Free-threading

#166

Post by willseth »

rfoo wrote: post #124
willseth wrote: post #98

Earlier quoted context omitted.

This is misleading. Most of the compute intensive work in Numpy releases the GIL, and you can use traditional multithreading. That is the case for many other compute intensive compiled extensions as well.

No. Like the siblings said, say, you have a program which spends 10% time in Python code between these numpy calls. The code is still not scalable, because you can run at most 10 such threads in a Python process before you hit the hard limit imposed by GIL. There is no need to eliminate the 10% or make it 5% or whatever, people happily pay 10% overhead for convenience, but being limited to 10 threads is a showstopper…

Python has no threads or processes hard limit, and the pure Python code in between calls into C extensions is irrelevant because you would not apply multithreading to it. Even if you did, the optimal number of threads would vary based on workload and compute. No idea where you got 10.

Re: State of Python 3.13 performance: Free-threading

#167

Post by Shawnj2 »

saurik wrote: post #77
andai wrote: post #24

Earlier quoted context omitted.

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

The Python 2 to 3 thing was worse when they started: people who made the mistake of falling for the rhetoric to port to python3 early on had a much more difficult time as basic things like u"" were broken under an argument that they weren't needed anymore; over time the porting process got better as they acquiesced and unified the two languages a bit. I thereby kind of feel like this might have happened in the other…

Honestly I think a big issue is that it’s not just legacy code, it’s also legacy code which depends on old dependency versions. Eg there’s an internal app where I work stuck on 3.8.X because it uses deprecated pandas syntax and is too complicated to rewrite for a newer version easily.

Re: State of Python 3.13 performance: Free-threading

#168

Post by pansa2 »

DeathArrow wrote: post #133
eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

>Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. Have you heard of Mojo? It is a very performant superset of Python. https://www.modular.com/mojo

Mojo isn’t anywhere near a superset of Python. It doesn’t even support classes!

Re: State of Python 3.13 performance: Free-threading

#169

Post by stevofolife »

eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

Can you help me understand, if libraries like pandas and numpy also applies to your comment? Or are they truely optimized and you’re just referring to the standard Python language?

Re: State of Python 3.13 performance: Free-threading

#170

Post by VagabundoP »

Timon3 wrote: post #58
adamc wrote: post #34

Earlier quoted context omitted.

It's hard to comment on this without knowing more about the dependencies and when/how they changed their APIs. I would say if it was a major version change, that isn't too shocking. For a minor version change, it should be. Stuff that is actually included with Python tends to be more stable than random Pypi packages, though. NPM packages also sometimes change. That's the world.

The big difference is that npm will automatically (since 2017) save a version range to the project metadata, and will automatically create this metadata file if it doesn't exist. Same for other package managers in the Node world. I just installed Python 3.13 with pip 24.2, created a venv and installed a package - and nothing, no file was created and nothing was saved. Even if I touch requirements.txt and pyproject.to…

All that can be specified in a pyproject.toml.

As some posters mentioned uv takes care of a lot of that and you can even pin it to a version of python.

If it’s just a one off script you can get all the dep information in the script header and uv can take care of all the venv/deps for you if you transfer the script to another machine by reading the headers in a comment section at the start of the script.

All this is based on PEPs to standardise packaging. It’s slow but moving in the right direction.

Post reply on HN