GraalPy – A high-performance embeddable Python 3 runtime for Java

Your mileage may very much vary, much like pypy this is very inconsistent and highly dependent on your workload (as well as your dependencies).

My limited experience was that on re-heavy workload pypy is several times slower than cpython (~3x compared to 3.10) and graal is even worse (~6x compared to 3.11).

The number of patches is going down with time and many are trivial one liners, e.g. uvloop

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

    -        self.cython_always = False
    +        self.cython_always = True

That's the entire patch. Others are working around bugs in the C extensions themselves that a different implementation happens to expose, and can be upstreamed:

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

Still others exist for old module versions, but are now obsolete:

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

    # None of the patches are needed since 43.0, the pyo3 patches have been upstreamed

And finally, some are just general portability improvements. Fork doesn't exist on Windows. Often it can be replaced with just starting a sub-process.

So the patching situation has been getting much better over time, partly due to the GraalPy team actively getting involved with and improving the Python ecosystem as a whole.

There is basic GraalPy support in Maturin[0] and PyO3[1], the problem is often that packages require older Maturin/PyO3 versions and/or they use CPython-isms, semi-public APIs, etc., but it is getting better, for example [2].

It is fair to say that large projects with a huge set of dependencies will likely face some compatibility issues, but we're working on ironing this out. There is GraalPy support in setup-python GitHub action. GraalPy is supported in the manylinux image [3]. Hopefully soon also in cibuildwheel [4].

[0] https://github.com/PyO3/maturin/pull/1645 (merged)

[1] https://github.com/PyO3/pyo3/pull/3247 (merged)

[2] https://github.com/pydantic/jiter/pull/135 (merged)

[3] https://github.com/pypa/manylinux/pull/1520 (merged)

[4] https://github.com/pypa/cibuildwheel/pull/1538

To be fair, this also happened when Graal was released for Java. Give it another go in 3-6 months, the Graal team will have improved interoperability massively.

It is a chicken (interpreter) and egg (dependencies) problem. You cannot fix the dependency problems without the interpreter. Neither can you release an interpreter with full dependency support.

For projects using GraalPy, I'd wager that most would vendor all their dependencies at the start of the project and upgrade along the way. I have shipped a couple products with Jython, and very little 3rd party code was used and almost none of the standard library, it was all driving Java from the same project.

So it does have to do with scale but in the opposite direction. Big long projects will want to adopt something like GraalPy because of how long the project will take.

Yes, apparently it can

https://www.graalvm.org/dev/reference-manual/python/Native-E...

> CPython provides a native extensions API for writing Python extensions in C/C++. GraalPy provides experimental support for this API, which allows many packages like NumPy and PyTorch to work well for many use cases. The support extends only to the API, not the binary interface (ABI), so extensions built for CPython are not binary compatible with GraalPy. Packages that use the native API must be built and installed with GraalPy, and the prebuilt wheels for CPython from pypi.org cannot be used. For best results, it is crucial that you only use the pip command that comes preinstalled in GraalPy virtualenvs to install packages. The version of pip shipped with GraalPy applies additional patches to packages upon installation to fix known compatibility issues and it is preconfigured to use an additional repository from graalvm.org where we publish a selection of prebuilt wheels for GraalPy. Please do not update pip or use alternative tools such as uv.

I am willing to live with Python as the Lisp we deserve to have, on this AI wave, when it finally gets a proper JIT story we can rely on, regardless of the workload.

Currently it is a mix and match of an herculean engineering effort mostly ignored by the community (PyPy), DSLs for GPGPUs, bunch of C and C++ libraries that people keep referring to as "Python" when any language can have similar bindings, jython, IronPython, GraalPy,...

So it isn't for lack of trying, at least we finally have CPython folks more welcoming to performance improvements, and JITs.

The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.

Looks like all of that would run in a native sandbox environment which in turn is called from the Python running on the JVM. So, maybe it simplifies interop, but whether it's straightforward to get full performance from the native layer (especially GPU/multicore) is an open question.

Hi, what's the deployment process like? Is there a program similar to warbler (for jruby) that builds a jar for a python program?

EDIT: I tried the native binary command here on a simple hello world script.

It downloaded some stuff in the background, built the entire python and java and embedded it into a 350 MB ELF binary on linux after 15 minutes of using 24 GB RAM and 100% CPU.

But I'd much prefer a smaller jar file which I can distribute cross-platform.

https://www.graalvm.org/uploads/quick-references/GraalPy_v1/...

What's the GIL/threading story there?

Why would they benefit? When duckdb/Polaris are being used correctly, all the work is happening in the native stack. It should already be very fast compared to the Python runtime.

I recently moved a large ETL process that was mostly Python runtime processing to pyarrow/Polaris and wrote all the ETL logic in SQL. I've seen processes that used to take a week to run drop to about an hour (no exaggeration).

Python implementations naturally don't have any GIL in regards to JVM or CLR variants, there is no such thing on those platforms.

YAML and JSON have both tried to replicate the XML tooling experience, only worse.

Schemas, comments, parsing and schema conversions tools.

Happily, you can ignore the Maven XML and use Gradle instead, it's the next codeblock on the page, after "or":

    implementation("org.graalvm.polyglot:polyglot:24.1.0")
    implementation("org.graalvm.polyglot:python:24.1.0")

I mean, if you're trying to embed one language in another, please don't be surprised when the quickstart guide has a couple of examples containing a few lines of code written for the embedding language and its package manager(s).

I worked at a company where data scientists wrote python code using pandas and we had port it to java and a library called keanu that was very useful but soon became unmaintained.

Of course this was very time consuming and unrewarding, all because only java applications could be deployed to production due to a stupid top-down decision.

This GraalPy sounds like something I wish existed back then.

Ghidra embeds Python scripting via Jython, which is stuck on Python 2. Switching to GraalPy would allow Python 3 scripting.

Any other Java programs that want a scripting engine could use it as well.

Besides all the nice answers given by others, a big one was not mentioned: performance!

Graal can do pretty advanced JIT-compilation for any Graal language, plus you can mix-and-match languages (with a big chunk of their ecosystems) and it will actually compile across language boundaries. And we haven’t even mentioned Java’s state of the art GCs that can run circles around any tracing GC, let alone the very low throughput reference counting.

Picture working for a big, non-tech corporation. Your BU only does Java because it has always been thus and Jeff the SVP is a law grad and doesn't want anything to change because of perceived risk. GraalVM allows smart people who have to work within such limitations to still write (mostly) the software they want while still vaguely relating it to Java for decision makers.

Minecraft Mods can only be written in Java and I want my kid to learn python.

Jython is still 2.x and it'd be nice to let my kid write a minecraft mod in python. Not a business use case but a use case.

Maybe this would be an interesting alternative runtime environment for PySpark? I think currently PySpark runs in Python and somehow interacts with a JVM and relies on copying data from one to the other.

Data scientists trapped in bureaucracy?

I am assuming - With this, JVMs needing integration with LLMs can embed LLMs in JVM instead of making outbound API calls. If my assumption is right - wouldn't this improve performance of consumer applications?