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

Original Article ↗ Hacker News Discussion ↗

Runtime, Version, and GIL

  • Targets Python 3.11.
  • GraalPy does have a GIL, mainly to support CPython-style native extensions; contrast is drawn with Jython/IronPython that avoided a GIL by dropping C extensions.
  • Discussion notes CPython’s PEP 703 nogil effort, but that’s separate from GraalPy.

Native Extensions, ML, and Data Stack

  • GraalPy offers experimental support for the CPython C API (not ABI), so wheels built for CPython cannot be reused; packages must be rebuilt with GraalPy’s toolchain.
  • A GraalPy-specific pip plus an extra wheel repo is used and must not be replaced or upgraded; tools like uv are discouraged.
  • Some common data/ML libs (NumPy, PyTorch, pandas, matplotlib) can work; DuckDB and Polars are not yet supported.
  • Performance and usability of GPU/multicore native code through this path are considered promising but still “open questions.”
  • HPy and the “limited C API” are mentioned as future ways to improve extension portability.

Performance

  • Benchmarks from “Are-we-fast-yet” show GraalPy ≈17× faster than CPython 3.11 and ≈2× faster than PyPy on that suite; Graal EE ≈1.3× faster than CE.
  • Others report real workloads (e.g., regex-heavy) where GraalPy is 6× slower than CPython, stressing that “your mileage may vary.”
  • Debate over benchmarks: some want interpreter-only measurements; others care more about end-to-end, FFI-heavy applications.

JVM Integration, Deployment, and Tooling

  • Can run on GraalVM JDK, Oracle JDK, and OpenJDK; JIT optimizations require GraalVM or experimental options.
  • Dependencies can be pulled in via Maven or Gradle; Gradle preferred by some for verbosity reasons but has its own issues.
  • Standalone native binaries are possible but currently large and slow to build; using jars on the JVM is suggested as more practical.
  • Interop can mix languages (Java, Scala, Clojure, etc.) in one process; potential speed and memory advantages over microservices boundaries.

Use Cases

  • Embedding Python into large Java-only environments (corporate stacks, Spark, JVM apps needing LLMs).
  • Replacing Jython for tools like Ghidra and Minecraft modding with Python 3 support.
  • Possible alternative runtime for PySpark-style workloads and Clojure/JVM ecosystems.

Compatibility and Ecosystem Maturity

  • Current pain points: some tools (e.g., maturin, uv) don’t fully support GraalPy; missing POSIX features like fork/execve cause issues.
  • GraalPy applies many small patches to popular libraries; number and intrusiveness of patches is reportedly decreasing over time.
  • Skepticism remains about adopting GraalPy for large, dependency-heavy existing projects versus greenfield JVM-centric ones.

Oracle / GraalVM Positioning

  • GraalPy is part of the broader GraalVM stack; there’s a free Community Edition and an Enterprise Edition that is often free to use but has a commercial angle.
  • Some participants question Oracle’s long-term intentions, others note Graal features already enhance Oracle products.