In Java, there are multiple languages that compile to Java bytecode and can run on the JVM -- Clojure, Groovy, and Scala being the main ones I can remember off the top of my head.

However, Python also turns into bytecode (.pyc files) before being run by the Python interpreter. I might just be ignorant, but why aren't there any other programming languages that compile to python bytecode?

Is it just because nobody bothered to, or is there some kind of inherent restriction or barrier in place that makes doing so difficult?

  • 32
    ...because they don't want to deal with the GIL? ;) Commented May 17, 2012 at 0:04
  • 6
    Instincts would tell me that it has a lot to do with just how mature the JVM is, well specified, and the JVM is on virtually all platforms or stupid easy to acquire.
    – Rig
    Commented May 17, 2012 at 0:26
  • 4
    I suspect also that most JVMs are much faster than python's interpreters. Commented May 17, 2012 at 3:32
  • 22
    By targeting Java bytecode, you get all the features of a JVM (security, performance, portability, scalability, and so on). Targeting Python bytecode doesn't get you very much. Commented May 17, 2012 at 4:00
  • 3
    Python bytecode is not recognised by later versions of the Python interpreter. How can anyone implement a programming language that compiles to Python bytecode?
    – Gus
    Commented Jul 21, 2012 at 14:47

6 Answers 6


Simple - last time I checked, Python had no formal specification, including its bytecode. CPython is the spec, and bytecode portability is IIRC not required. Thus, it's a moving, undocumented target designed for a specific language.

  • 24
    In fact, the details of the bytecode format often change between minor versions, and even the 99% compatible PyPy doesn't even try (in fact, they add their own bytecode instructions).
    – user7043
    Commented May 17, 2012 at 9:22
  • 2
    Note: Python --the language-- has a formal specification (see the "PEPs"). The 'Python Virtual Machine' has not. This is indeed unlike (eg) Java, where both are specified.
    – Albert
    Commented Jun 17, 2018 at 19:17

There are multiple JVM languages because there were talented people who wanted to write code that would work with existing Java code, but they didn't want to write Java.

Apparently there are no programmers who want to work with existing Python code, but hate Python enough to port another language to the Python bytecode interpreter.

You can look at this in two ways: there are alternative languages for the JVM because Java is so widespread, or there are no alternative languages for the Python bytecode interpreter because Python doesn't suck.

  • 8
    I hope you are not implying that Java sucks or Java sucks more than Python :-)
    – Giorgio
    Commented Jul 21, 2012 at 14:36
  • 10
    @Giorgio: I'm implying that the creators of Groovy, Scala, Clojure, etc. thought there was considerable room for improvement. Are you implying that Python sucks? Commented Jul 22, 2012 at 20:36
  • 8
    After working with python I would say "low suck factor" would be inaccurate. It bucks too much commonly accepted stuff and that whole 'self' thing is extremely counterproductive. In fact dumb. How doesn't a class method know where it belongs?
    – Rig
    Commented Jul 23, 2012 at 4:02
  • 7
    @Rig Personally, I think Python's approach is more elegant. The OO follows organically from the syntax rather than requiring a special keyword that looks like a variable. As to why class methods don't know where they are, it's because Python class definitions are just code, and this code isn't privledged because it happens to be located inside a class definition. You can define methods anywhere and add them to a class at runtime. In fact, you can take the same function and use it as a method in multiple classes, something that wouldn't really work with the this paradigm.
    – Antimony
    Commented Jun 6, 2013 at 6:23
  • 6
    I think it is a matter of VMs not languages. The JVM is a performant VM with a generational garbage collector, JIT, etc. While CPython uses reference counting and is an interpreter. It is CPython that sucks as a plataform. Btw hyhy exists.
    – PuercoPop
    Commented Jan 24, 2014 at 17:16

There are technical deficiencies such as the GIL in CPython, but few perceived language deficiencies, so the runtime isn't the selling point of the Python community. Exactly the opposite, there are more backend runtime options because of the dissatisfaction with the GIL/CPython implementation.

The Java Language is much more maligned than the JVM ( even in the Java community ).

The JVM is pretty well regarded in most circles; thus the desire for different/better language front ends with the benefits of the highly optimized back end JVM.


I say that Mason Wheeler is right. It's mostly an issue with the Global Interpreter Lock which makes concurrency a very thorny issue. Since there are other VMs that do concurrency really really well comparatively it makes sense to develop languages for those. Also Python has had a major language shift recently and many of the libraries have not caught up making compatibility a mild nightmare at times. For instance because I use PIL for vision work, I have to code in Python 2.7 or lower. This is not the case with the JVM or CLI setups which particularly in the latter's case were designed with language interop in mind.

Did some more research and apparently there are actually two GILs not just the one. The other controls Imports.

  • 1
    "GIL free" is one of the technical reasons mentioned on "Reasons that CPython programmers might be interested in IronPython" in the Python wiki.
    – yannis
    Commented May 17, 2012 at 1:26
  • 1
    @YannisRizos: Surely access to the .NET framework is not entirely inconsequential. Of course, it's possible that CPython users might be completely uninterested in that. Commented May 17, 2012 at 5:27
  • @RobertHarvey Ninja edited that. Although I don't think of "access to fancy new toys" as a technical reason (not that the toys aren't great), the wiki also mentions that IronPython is easier to extend.
    – yannis
    Commented May 17, 2012 at 5:35

The other answers make a lot of sense, but there are actually languages now that compile to Python. Where there's a will...

I don't know anything about these languages, but they seem to work by transpiling their source code to Python ASTs and letting Python compile the trees to bytecode, avoiding the problems mentioned in other answers.

Based on the comments, we currently know of three alternative languages that use the Python VM (feel free to add any others here):

  • Mochi Describes itself as a dynamically typed programming language for functional programming and actor-style programming.
  • Hy: Describes itself as a dialect of Lisp that's embedded in Python.
  • dg: Describes itself as a (technically) simple language that compiles to CPython bytecode.
  • 2
    Also worth mentioning HyLang
    – ideasman42
    Commented May 5, 2016 at 11:49
  • 1
    And dg.
    – hakatashi
    Commented Aug 31, 2016 at 19:22
  • Hissp now too.
    – gilch
    Commented Nov 6, 2021 at 22:52

Another reason is that the JVM is highly optimized, well-evolved, and extremely complete ecosystem. On it's own, it competes extremely well with any of the other compiled languages. (I won't say that it's the best general purpose VM out there, but I've certainly banked my career on that.) So getting access to the JVM, short of writing bytecode, is desirable in itself.

However, the Python VM is good, but (nothing against Python) has some serious shortcomings. The Python runtime environment suits the dynamic nature of the language well, but can really surprise you when you get familiar with its memory usage, global locking, or threading model.

In head-to-head comparisons, the JVM is typically twice as fast as the Python VM. The JVM (surprizingly) even competes well with natively compiled code, based on the "hot" optimizations it performs. And that's not even counting the more sophisticated thread handling, etc.

I love Python, I really do, and hate to say it, but sometimes the performance just kicks me in the teeth -- otherwise, why would critical Python libraries like numpy or scipy have to fall back into C code?

In other words, people who gravitate to Python do so because they like the language. But if you want to write a brand new language to suit your preferences, you're much better off compiling to the JVM, because your new idiosyncratic language will start off in one of the best (subjectively, maybe the best) operating environments available.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.