Live data from Hacker News

Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

fidget-spinner.github.io

131–140 of 164 posts

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#131
post #61
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript. Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution. Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how f…

See Smalltalk, Self and Common Lisp for highly dynamic languages with good enough JIT, the first two having their research contributed to Hotspot and V8.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#132

Earlier quoted context omitted.

genuinely curious, doesn't JS's proxy objects and prototype-based MRO have a similar performance impact in theory?

Yeah, I don't see how Python is fundamentally different from JavaScript as far as dynamicism goes. Sure Python has operator overloading, but JavaScript would implement those as regular methods. Pyrhon's init & new aren't any more convoluted than JavaScript's constructors. Python may support multiple inheritance but method and attribute resolution just uses the MRO which is no different than JavaScript's prototype cha…

Urban myths.

Most people that parrot repeat Python dynamism as root cause never used Smalltalk, Self or Common Lisp, or even PyPy for that matter.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#133
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

Even though Javascript is quite dynamic, Python is much worse. Basically everything involves a runtime look-up. It's pretty much the language you'd design if you were trying to make it as slow as possible.

Just like Smalltalk and Self.

Which can change on the fly anything that is currently executing in the image.

Also after breaking into the debugger, the world can be totally different after resuming execution at the trap location.

Then there are nice primitives like a becomes: b. where all occurrences of a get swapped with b.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#135
post #94

So…if the Python team finds tail calls useful, when are we going to see them in Python?

They find them useful as a performance optimization, not as a design tool. This optimization is not relevant to Python code because it relies on the optimization passes the compiler makes.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#136

The money shot (wish this were included in the blog post): # if defined(_MSC_VER) && !defined(__clang__) # define Py_MUSTTAIL [[msvc::musttail]] # define Py_PRESERVE_NONE_CC __preserve_none # else # define Py_MUSTTAIL __attribute__((musttail)) # define Py_PRESERVE_NONE_CC __attribute__((preserve_none)) # endif https://github.com/python/cpython/pull/143068/files#diff-45b... Apparently(?) this also needs to be attached…

[flagged]

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#137

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

Well, using MAUI instead of Avalonia or Uno was the mistake.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#140

Earlier quoted context omitted.

In the near future we will use lazy imports :) https://peps.python.org/pep-0810/

This can't come soon enough. Python is great for CLIs until you build something complex and a simple --help takes seconds. It's not something easily worked around without making your code very ugly.

It's not that hard to handle --help and --version separately before importing anything.
Post reply on HN