The problem is that the underlying vendor "operating system" forces you to use events and callbacks for everything. Disregarding sockets for the moment, we currently can't even run a basic Python script that loops flashing an LED and pausing for 10 seconds. That's because the vendor OS expects you to return very quickly from any user code.
So, the first thing we need to do is make the entire system compatible with the Python execution model, ie no callbacks. As part of this it just so happens that sockets become synchronous as well.
Once this is done we have a solid (and conventional, not forced upon us by the vendor) foundation to work from. Then we can build the Python way of doing async IO if needed using the asyncio framework (and perhaps the new async/await keywords).
From that link it seems that Python is used at NASA exclusively in ground-based systems. In contrast, the MicroPython+ESA collaboration is supposedly also looking at using the language in "payloads", ie things that go into space.
A lot of the internals are significantly different, and would be difficult to back port. Eg, a Micro Python object is a machine word which might be a pointer to a real object, a small integer, or an interned string. By stuffing small integers (and strings) into the unused bit-space of a machine word, Micro Python can do a lot of integer operations without allocating heap RAM. This is in contrast to CPython where all integers are on the heap (although the ones below 257 are cached).
Another example: calling a function in CPython requires a heap allocation of the call frame. In Micro Python this is generally not needed (unless the function call is significantly complicated).
Actually, most of that SLOC is in the stmhal/ port, of which ~100k is the ST library.
The true count comes from the py/ directory, for which cloc gives only 25k. And there are a lot of extra bits there, eg the inline assembler, the Thumb and X64 assembler helpers, etc.
EDIT: without the additional assemblers, cloc gives 22k. Remember that Python has ints, floats, complex and bignum, and these are all included in Micro Python. So that 22k SLOC includes complex arithmetic and a 1k bignum implementation.
> What parts of Python 3 syntax are missing? Which parts of the library don't compile?
The only things that don't compile properly are certain uses of "super()". super() without arguments is a very strange beast that captures the first argument of the function (interpreting it as the self object), and needs to infer its class.
Other than that, all the Python scripts in the Python 3 standard library will compile.
Yes, stat, cs and math researchers don't use arXiv as exclusively as physicists. And we don't pick up references in those areas as well as we do for physics papers, so they are small and not well placed. We plan to improve the citation extraction for math and cs so they have a proper representation in the map.
The problem is getting the data: a list of papers and their references/bibliography. The great thing about the arXiv is that the papers are open-access, that it is updated daily, and that the daily-update is immediately available to data-mining. Is there a similar thing for med/biomed?
So, the first thing we need to do is make the entire system compatible with the Python execution model, ie no callbacks. As part of this it just so happens that sockets become synchronous as well.
Once this is done we have a solid (and conventional, not forced upon us by the vendor) foundation to work from. Then we can build the Python way of doing async IO if needed using the asyncio framework (and perhaps the new async/await keywords).