Pyjion - A JIT for Python based upon CoreCLR
C++ Other
Switch branches/tags
Nothing to show
Clone or download
Latest commit 5f55e71 May 14, 2018
Failed to load latest commit information.
CoreCLR @ c6de64f Use release/1.0.0-rc2 branch of CoreCLR, and fix resulting breakages.… May 21, 2016
Docs Don't include Sphinx build output in wc May 24, 2016
Patches/CoreCLR Remove Python patches May 30, 2017
Perf Update benchmark info May 13, 2016
Pyjion Revert "Linux" May 14, 2018
Python @ 2773add Move tracking branch to 3.6 May 20, 2017
Test Get rid of TraceInfo, move state into PyjionJittedCode May 30, 2017
Tests Fixup formatting Jun 2, 2017
Tools Fix generated output to handle when a type doesn't lead to a branch Sep 28, 2015
.gitattributes Update CoreCLR to a newer commit so that it will build under VS 2015 … Dec 3, 2015
.gitignore Don't include Sphinx build output in wc May 24, 2016
.gitmodules Use the release branch of CoreCLR May 19, 2016
BuildDebugPython.bat Make building from the command-line much easier Apr 12, 2016
BuildDeps.cmd Use release/1.0.0-rc2 branch of CoreCLR, and fix resulting breakages.… May 21, 2016 Add code of conduct referenced in Jun 21, 2017 Make building from the command-line much easier Apr 12, 2016
CopyFiles.bat Fixup EXTENDED_ARG handling for branches May 26, 2017
DebugBuild.bat Make building from the command-line much easier Apr 12, 2016 Update Jul 21, 2015
PatchDeps.bat Remove Python patches May 30, 2017 Remove Python patches May 30, 2017
Pyjion.sln add tracing and specilization of functions based upon tracing informa… Apr 5, 2016 Add a note about frequency of progress Jan 2, 2017


Designing a JIT API for CPython

A note on development

This is a side project at work for the project maintainers, and so progress can be sporadic. In spite of that we do accept contributions at any time and will attempt to respond to them promptly.


What are the goals of this project?

There are three goals for this project.

  1. Add a C API to CPython for plugging in a JIT
  2. Develop a JIT module using CoreCLR utilizing the C API mentioned in goal #1
  3. Develop a C++ framework that any JIT targetting the API in goal #1 can use to make development easier

Goal #1 is to make it so that CPython can have a JIT plugged in as desired (CPython is the Python implementation you download from That would allow for an ecosystem of JIT implementations for Python where users can choose the JIT that works best for their use-case. And by using CPython we hope to have compatibility with all code that it can run (both Python code as well as C extension modules).

Goal #2 is to develop a JIT for CPython using the JIT provided by the CoreCLR. It's cross-platform, liberally licensed, and the original creator of Pyjion has a lot of experience with it.

Goal #3 is to abstract out all of the common bits required to write a JIT implementation for CPython. The idea is to create a framework where JIT implementations only have to worry about JIT-specific stuff like how to do addition and not when to do addition.

Is there a Python Enhancement Proposal (PEP) for this?

We have written a PEP, it was accepted by the Python development team, and will be implemented in Python 3.6.

How do you pronounce "Pyjion"?

Like the word "pigeon". @DinoV wanted a name that had something with "Python" -- the "Py" part -- and something with "JIT" -- the "JI" part -- and have it be pronounceable.

How do this compare to ...


PyPy is an implementation of Python with its own JIT. The biggest difference compared to Pyjion is that PyPy doesn't support all C extension modules without modification unless they use CFFI or work with the select subset of CPython's C API that PyPy does support. Pyjion also aims to support many JIT compilers while PyPy only supports their custom JIT compiler.


Pyston is an implementation of Python using LLVM as a JIT compiler. Compared to Pyjion, Pyston has partial CPython C API support but not complete support. Pyston also only supports LLVM as a JIT compiler.


Numba is a JIT compiler for "array-oriented and math-heavy Python code". This means that Numba is focused on scientific computing while Pyjion tries to optimize all Python code. Numba also only supports LLVM.


IronPython is an implementation of Python that is implemented using .NET. While IronPython tries to be usable from within .NET, Pyjion does not have a compatibility story with .NET. This also means IronPython cannot use C extension modules while Pyjion can.


Psyco was a module that monkeypatched CPython to add a custom JIT compiler. Pyjion wants to introduce a proper C API for adding a JIT compiler to CPython instead of monkeypatching it. It should be noted the creator of Psyco went on to be one of the co-founders of PyPy.

Unladen Swallow?

Unladen Swallow was an attempt to make LLVM be a JIT compiler for CPython. Unfortunately the project lost funding before finishing their work after having to spend a large amount of time fixing issues in LLVM's JIT compiler (which has greatly improved over the subsequent years).

Nuitka and Shedskin?

Both Nuitka and Shedskin are Python-to-C++ transpilers, which means they translate Python code into equivalent C++ code. Being a JIT, Pyjion is not a transpiler.

Are you going to support OS X and/or Linux?

Yes! Goals #1 and #3 are entirely platform-agnostic while goal #2 of using CoreCLR as a JIT compiler is not an impedence to supporting OS X or Linux as it already supports the major OSs. The only reason Pyjion doesn't directly support Linux or OS X is entirely momentum/laziness: since the work is being driven by Microsoft employees, it simply meant it was easier to get going on Windows.

Will this ever ship with CPython?

Goal #1 is explicitly to add a C API to CPython to support JIT compilers. There is no expectation, though, to ship a JIT compiler with CPython. This is because CPython compiles with nothing more than a C89 compiler, which allows it to run on many platforms. But adding a JIT compiler to CPython would immediately limit it to only the platforms that the JIT supports.

Does this help with using CPython w/ .NET or UWP?


Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact with any additional questions or comments.