99% of the time, when anyone says
Python, they mean CPython.
So Is Python Different from CPython?
As the green intro tip implies, colloquially, the two are identical.
However, for language nerds, Python can be considered an interface. Henceforth, when I write Python in block text, I mean the interface.
Python is the abstract concept of all the syntax (def, class, =, in, not, dict) and, depending on who you ask, the full standard library. It is not the actual software you download from python.org. That is the implementation.
CPython is the reference implementation of Python, which you do download from python.org! There are also other implementations like Cython, PyPy, and Jython. More on this in the next section.
There are other languages that do this like Ruby with Ruby and JRuby and ECMAscript with Javascript and ActionScript.
One could even argue that Java has multiple implementations, in the form of Oracle Java and Android Java. Although litigious companies are not nearly as kind to this sort of copying as open source communities.
There’s nuances in interface and implementation. Strict definitions of them are not portable between communities. Any attempt at defining exact meanings quickly break down like trying to define life.
Just know that a language itself is the interface (how you write it in a text editor), and the software is the implementation (how to convert that language into bits for the machine). For most langauges, the distinction is meaningless because the reference implementation written by the language creators will be the only complete and usable implementation.
CPython (Or just “Python”)
When most developers say Python, they mean CPython, the virtual machine, the interpreter, and the compiler, all vetted by the Python OSS maintainers. They, of course, also mean the language because lumping language and implementation together simplifies unnecessary details.
This is what you get when you run brew install python on your Mac or download and install from python.org. It is the reference implementation of Python.
Using the reference has many advantages
- Will be on the latest version of the language
- Always developed alongside language features
- Will be the least buggy (Usually)
- Will have the most compatability with 3rd party libraries.
On the downside, CPython is slow, slower than many other implementations.
To counteract this, CPython, being built for C, allows for easy interoperability with C and C++ compiled code, which can be written to be extremely fast.
This is why CPython is so popular for research and machine learning. Researchers are able to write the computationally expensive parts in C or C++ and then glue them together with very readable Python code.
CPython, being interpreted, also allows for very quick distribution and modification as well as editing code during runtime. The ultimate expression of this is IPython, now called Jypyter Notebook, an interactive shell that can output rich GUI elements.
Jython, IronPython, Cython, PyPy, and More
These alternative implementations of Python are usually trying to tap into another language’s virtual machine to make use of another ecosystem of libraries running on that VM. Python is an interesting case where there are also many implementations that started as research projects or forks of CPython in an attempt to speed it up.
Jython
As the name implies, it is Python running in the Java VM, allowing Jython access to the huge Java ecosystem. This variant is likely1 the most used outside of the reference implementation.
IronPython
Python implementation written in C# to run on top of the Microsoft runtime and take advantage of .NET libraries.
Cython
Cython is a strange one. It transpiles Python to C and thus has very good C interoperability. Importantly, this is different from CPython (yes, I know) in that it has additional syntax and features allowing for direct interaction with C code and not just C-compiled libraries.
I strongly suspect the original authors chose the name just to mess with all Python beginners.
PyPy
PyPy is another strange one. It is a Python implementation written with a JIT compiler which means it can run certain workloads much faster than CPython. It started as a research project to build a JIT compiler for Python and has endured as one of the older Python implementations. A big reason is probably because it has good interoperability with Django, the extremely popular web framework that many startups used in the late 2000s to mid 2010s before Node.js became dominant.
Other Implementations
Unsurprisingly, Python’s open nature and attractiveness to researchers lead it to have many implementations.
Many of these implementations were also sponsored by aforementioned startups trying to speed up their stack without completely rewriting everything in a different language.
The Future
“AI” development being the hot new thing means Python is quickly gaining interest again, harkoning back to the startup frenzy a decade ago.
A recently announced new implementation is Mojo. They don’t call themselves an implementation because it is technically a superset with additional functionality, but then so is Cython…..
Regardless of how they define themselves, Mojo is interesting because the backing company is headed by Chris Lattner of Apple Swift and LLVM fame. Whether this just becomes another random implementation or a true successor to CPython like Typescript with Javascript depends on how quickly they can gain traction and integrate with existing libraries.
I do not have access yet, but supposedly it packages the CPython VM to run all CPython libraries that do not have a Mojo equivalent yet so it will at least have the performance of CPython. But it’s still early days and writing a Django server will likely be quite difficult. It also seems to be only available in a web sandbox for now. They do plan to open source it which should at least gaurantee its survival if nothing else.
This implementation is ostensibly designed for machine learning because new models like StableDiffusion and GPT require so much computational power. But I suspect Chris could not help but also find all the frustrating parts of CPython and improve on them.
The performance boost is nice, but static variables, type checking, and non-monkeypatchable classes would allow for much more powerful static analysis and auto-completion. Combined with both corporate and OSS interest as well as a ton of funding, Python could see a Typescript-esque revolution in the near future and I welcome it wholeheartedly.
I have no proof other than anecdotally seeing past companies use it. The only other implementation I’ve seen used in commercial production software was IronPython, and only once. ↩