58

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?

user16764
  • 3,583
  • 1
  • 25
  • 22
Michael0x2a
  • 1,099
  • 1
  • 7
  • 22
  • 32
    ...because they don't want to deal with the GIL? ;) – Mason Wheeler May 17 '12 at 00: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 May 17 '12 at 00:26
  • 4
    I suspect also that most JVMs are much faster than python's interpreters. – Peter Smith May 17 '12 at 03: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. – David Schwartz May 17 '12 at 04: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 Jul 21 '12 at 14:47
  • Stand it on its head - why doesn't Python compile to an existing byte code, such as JVM ? – Mawg says reinstate Monica Dec 19 '14 at 09:02
  • 1
    @Mawg -- you may be interested in checking out Jython. It's an implementation of Python that compiles to Java bytecode and runs on the JVM. There's also Ironpython, which does the same thing, but for the CLR. – Michael0x2a Dec 19 '14 at 14:26
  • The lack of a formal specification, and the fact that it changes between Python versions makes it very hard to target. The closest viable alternative would be a source to source compiler to "compile" to Python source code (similar to how some C++ compilers output C code). – Kevin Aug 16 '15 at 05:29
  • @DavidSchwartz compiling to python bytecode gets you django, flask, sqlalchemy, numpy, scipy, pandas, pycuda, matplotlib, scikit-learn, nltk, sympy, scrapy, boto, lxml, docutils, etc. Even if the JVM has comparable offerings, I can understand why a pythonista already familiar with these libraries would still want to use them while yet seeking language features not offered by Python. – Aryeh Leib Taurog Dec 24 '15 at 15:08

6 Answers6

85

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.

p_l
  • 975
  • 6
  • 5
  • 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). –  May 17 '12 at 09: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 Jun 17 '18 at 19:17
57

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.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 8
    I hope you are not implying that Java sucks or Java sucks more than Python :-) – Giorgio Jul 21 '12 at 14:36
  • 9
    @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? – kevin cline Jul 22 '12 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 Jul 23 '12 at 04:02
  • 1
    @kevin cline: I was not implying that Python sucks. Personally I think that neither Python nor Java sucks and that both languages serve the purposes for which they were created pretty well. Of course, both languages have room for improvement (as most / all programming languages). Also, I do not know if I would consider Scala or Clojure improvements to Java or rather new languages based on the Java platform (JVM, standard libraries, etc): both contain many concepts that predate Java. – Giorgio Jul 23 '12 at 05:16
  • 2
    @Rig It's because Python's OOP was very, very barebones, so it exposed the self argument which is "hidden" in Java, C++, Ruby and others. So you have parts of the internals showing up. – p_l Jul 24 '12 at 22:05
  • 2
    Which is not elegant in the least. – Rig Jul 25 '12 at 11:08
  • 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 Jun 06 '13 at 06: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 Jan 24 '14 at 17:16
  • 3
    Python is a very nice language, but the library and ecosystem is getting really tired. There's little point replacing the language to access the libraries. – Carl Smith Jun 25 '14 at 01:51
  • 3
    @Rig: there is a fundamental conflict between an implied self/this variable and closures. Both are desirable, but having both leads to ambiguity. What is 'this' in the closure body? – kevin cline Sep 04 '14 at 10:00
  • 2
    Having `self` as an arg to the method makes it easier to follow what happens when you're passing it around with decorators and so on. It's just another reference to the instance. – Carl Smith Dec 18 '14 at 23:04
26

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.

10

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 1
    "GIL free" is one of the technical reasons mentioned on "Reasons that CPython programmers might be interested in IronPython" in the [Python wiki](http://wiki.python.org/moin/IronPython). – yannis May 17 '12 at 01: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. – Robert Harvey May 17 '12 at 05: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 May 17 '12 at 05:35
9

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.
Carl Smith
  • 695
  • 4
  • 13
7

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.

sea-rob
  • 6,841
  • 1
  • 24
  • 47