Which incidentely has a much better history with JIT adoption than Python, where the community has largely ignored PyPy.

Meanwhile Ruby has had MacRuby from Apple, later canceled, but the main developers went out creating RubyMotion.

Sun toyed with JRuby, it was even officially supported on Netbeans, then Red-Hat supported the project for a while. It was also one of the first dynamic languages on GraalVM, with TruffleRuby. GraalPy effort only came a couple of years later, and is still on baby steps.

As of 2025, the refernce implementation counts with YJIT, MJIT, TenderJIT, and MRuby 4 brings ZJIT to the party.

Exchanging Lisp for Python we went backwards in regards to performance in dynamic languages, in a distopian world where C, C++, Fortran libraries are "Python" libraries.

Nope they are bindings, and any language with FFI can have bindings to those same libraries, e.g. PyTorch can also be used in straight C++, or from Java.

I usually do REPL driven development in Python via emacs but you can tell it's not the natural way to do things, esp. if you start doing stuff with async. But I still feel that it makes me way more productive than I would otherwise be

It has a Tk based REPL and debugger in the box, and I guess nowadays Jupiter notebooks is the closest to a Lisp Machines/Interlisp-D kind of development.

There are the IDE integrations as well.

Pity is the lack of (compile ...) and (decompile ....), or similar.

Which by the way is available in Julia.

There is a good compromise with reflection, attributes, metaclasses, one line lambdas, comprehensions

Now the lack of machine code generation for something Lisp was doing in the 1960's, Smalltalk in the 1980's, SELF in 1990's, and having to fall back on C, C++ and Fortran is bonkers.

Thankfully this is finally becoming a priority for those willing to sponsor the effort, and kudos to those making it happen.

I would rather use Common Lisp, in something like Allegro, but I will hardly find such a job, thus only arguing about language features doesn't take us that far.

In Python, an iterator raises a StopIteration exception to indicate to the for loop that the iterator is done iterating.

In Python, the VM raises a KeyboardInterrupt exception when the user hits ctrl+c in order to unwind the stack, run cleanup code and eventually exit the program.

Python is a quite heavy user of exceptions for control flow.

Typically yes, but not in Python. In Python it is quite common and accepted, and sometimes even recommended as Pythonic to use exceptions for control flow. See iterators, for example.

I really dislike this too, but that’s how it is.

All iterators in Python use exceptions for flow control, as do all context managers for the abort/rollback case, and it is generally considered Pythonic to use single-indexing (EAFP) instead of check-then-get (LBYL) - generally with indexing and KeyError though and less commonly with attribute access and AttributeError.

[heavy green check mark]

    try:
        data = collection['key']
    except KeyError:
        data = ..try something else..

    if 'key' in collection:
         data = collection['key']
    else:
         data = ..try something else..

I would like to introduce you to StopIteration.

The comment you mention applies to source code encoding and it's obsolete for Python 3 since the beginning. This is about something else: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

Yep, ruff has a warning for this exact issue.

I'm the author of the thread you linked. Community stewardship is actually happening in some form or another now.

3.15 has some JIT upgrades that are in-progress. This has a non-exhaustive list of them https://docs.python.org/dev/whatsnew/3.15.html#upgraded-jit-...

It's not that uncommon for libraries to declare an overly strict maximum version, even if the code would actually work, because they can't know that at time of setting the version constraint.