State of Python 3.13 performance: Free-threading • Hacker News Board

Re: State of Python 3.13 performance: Free-threading

#191

Post by wruza » Sat, Nov 09, 2024, 2:14 PM UTC

holdenweb wrote: post #187

wruza wrote: post #36

Earlier quoted context omitted.

Could you point to any specific major breaking changes between 3.x releases? I can not, but I can tell you that anything AI often requires finding a proper combination of python + cuXXX + some library. And while I understand cu-implications, for some reason python version is also in this formula. I literally have four python versions installed and removed from PATH, because if I delete 3.9-3.11, they will be needed n…

They'll all co-exist. Add them all to your PATH, make one the default python3, and request specific versions when they are required.

I don't need the default, because which python to choose depends on project's dependencies which may work only for specific versions. And then you build a venv and it lives there. It's not some safety measure, it's a natural choice. I don't need bare `python` command outside of venv.

That said, 3.12 doesn't even have python312.exe in its folder. If 3.13 follows, having both of them in PATH is useless.

Re: State of Python 3.13 performance: Free-threading

#192

Post by movpasd » Sun, Nov 10, 2024, 8:17 PM UTC

almostgotcaught wrote: post #181

6gvONxR4sf7o wrote: post #96

Earlier quoted context omitted.

> 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. I don't even understand what this means. If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. Restricted subsets of languages are wildly popular in programming language…

> If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. You either are performing some wordplay here or you don't understand but type hints are not part of the semantics at all: since they are not processed at all they do not affect the behavior of the function (that's what semantics means). EDIT: according to the language s…

That's not strictly true -- type annotations are accessible at runtime (that's how things like dataclasses and pydantic work).

Re: State of Python 3.13 performance: Free-threading

#193

Post by gilch » Tue, Nov 12, 2024, 8:26 PM UTC

adamc wrote: post #45

eigenspace wrote: post #38

Earlier quoted context omitted.

There are ways to design languages to be dynamic while still being friendly to optimizing compilers. Typically what you want to do is promise that various things are dynamic, but then static within a single compilation context. julia is a great example of a highly dynamic language which is still able to compile complicated programs to C-equivalent machine code. An older (and less performant but still quite fast) exam…

Not disputing it, but people don't pick Python because they need the fastest language, they pick it for friendly syntax and extensive and well-supported libraries. I loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network…

> I loved Lisp, but none of the lisps have anything like Python's ecology.

Try Hissp (https://github.com/gilch). Lisp programming and Python's ecosystem.