* it keeps CPython as is.
* hence retains compat with extensions.
* but still has the potential to improve performance like pypy.
* and yet can be shipped just as an additional compiled lib inside the Python dist.
Yep. They are MS ingenieers, of course Windows is easier for them. Plus it's good publicity. Given that they are paying for it, it's fair they start like that.
Exactly, we started on Windows out of ease-of-start/momentum. There are absolutely no plans to make this a Windows-exclusive. Basically we want to show this work pans out before working before putting in the work to make it cross-platform (we have an open issue to move to CMake to help solve the cross-platform problem: https://github.com/Microsoft/Pyjion/issues/76).
One thing to note about the list of failing tests is the vast majority of them are due to a single bug (or two): https://github.com/Microsoft/Pyjion/issues/103 . And we currently only have 11 open bugs so the test failures make it look worse than it is.
From reading the description, and from what little I know about IronPython...
IronPython is a re-implementation of Python in C# which allows it to play nice with .NET. This is similar to Jython which is a re-implementation of Python in Java that plays nice with the JVM.
This project on the other had is not a re-implementation at all, but aims to augment the existing CPython implementation with JIT APIs and is using CoreCLR for the JIT.
What ericfrederich said is all accurate. We are also considering playing with ChakraCore as a JIT back-end as well once we are sure that our abstract interpreter code that drives the JIT emission code is compatible with Python semantics.
It's too early. We want to prove to ourselves that we can get the performance we want before proposing the changes we think we want to CPython's C API.