Yes it can with caveats. A lot of packages that use native code work but not all. The Python ecosystem is pretty messy and doesn't care much about alternative

Yes it can with caveats. A lot of packages that use native code work but not all. The Python ecosystem is pretty messy and doesn't care much about alternative impls, so some packages do silly things like hard-code that the interpreter must be named "CPython". Others make extremely deep assumptions about the CPython internals that GraalPy can't meet. There's no equivalent of a standardized interface like JNI in the Python world yet (there's an effort called HPy but it's new). GraalPy comes with a modified pip that knows how to patch popular packages that do bad things to work with it. Still, GraalPy actually can use native extensions and in theory in future even sandbox them (or maybe even today, I forget the status). Most alternative implemenations were never able to do it at all! Now if you want to sandbox Python code you must also be able to sandbox arbitrary C/C++. Python is so slow that almost any real program will rely on extensions. The tech stack can do it and it's been done for other languages, because Graal can actually JIT compile and sandbox LLVM bitcode as well. In that case you recompile with a special toolchain and the native code always thinks it's running on Intel Linux. But that has some warmup time impacts and you have limited access to hardware/the OS in that mode obviously, as with any sandboxing. For example PyTorch couldn't be sandboxed in that way. Also I don't know if GraalPy supports sandboxing yet, it might be taking a back seat to other priorities like more ecosystem compatibility.