Programming

I'm not going to tell you you shouldn't do that, I think everybody else has done enough telling others what to do. I'll try to focus more on what you'd need to accomplish and why what you're asking hasn't been done.

Building an OS involves a lot of complex work using very low level calls. The easiest way to think about it, IMO, is that whatever language you use needs to be able to communicate directly with the hardware without any abstraction between the code and the hardware after it's compiled.

Basic Python, out of the box, requires multiple levels of abstraction to run.

(I'm simplifying here) You write code which is run through an interpreter. The interpreter is a compiled application that translates Python into code the operating system can understand. Then the operating system translates that to calls the hardware can understand.

In that process, the python code is translated to byte code, assembly, and machine code. The Python virtual machine handles memory management for you. It also handles some processing concepts for you.

You'd need to start by finding (or inventing) a solution that compiles Python to assembly without the need of an interpreter or OS in between you and the hardware. It's worth noting here that Python itself isn't even fully written in Python and is instead written largely in C because Python isn't a compiled language. You'd then need to extend Python with the ability to completely manage memory and processor threads without the VM. You'd need to do that because that's really the main purpose of an operating system.

Something we learn in programming is choosing the right tool for the job. Python isn't a great option for this type of project because the requirements just to get to where you can start are so high that it's not really considered worth while. Is it possible, yes, in theory. But without the python interpreter and VM, you'd have to ask if you're really developing Python or something else that just uses pythons syntax.

What OS will run the Python interpreter?

you could in micropython at least. it's not unixy but for example see https://github.com/Rybec/pyRTOS

To program an operating system, you need deep knowledge how internals work. The language you are using needs low level access. And I don't think a garbage collected language is a good fit for an operating system either. Especially an interpreted language like Python requires an interpreter to run under. And Python is not the fastest language either, which is fatal for a low level os functionality.

What do you expect from turning C code into Python code? Python does not have low level access, it requires C (even Rust requires some C functionality). I don't think it is even possible to write an OS purely in Python.

The essence of your answers is "yes, but...". And the "but" is mostly about how slow Python is in contexts that need to be astonishingly fast.

It depends how complex the hardware is and how much time we're willing to waste.

Technically, when I deploy a Python program to a BBC Microbit, that's (more or less) what is happening. Pure Python code is making every decision, and is interacting directly with all available hardware.

We could still argue semantics - virtually no (modern) computer exists that isn't running at least one tiny binary compatibility driver written in C.

I believe the compiled C binary on a BBC Microbit to bootstrap a pure Python OS is incredibly small, but my best guess is that it's still present. The C library for Microbit needed to exist for other languages to use, and Python likes calling C binaries. So I don't imagine anyone has recreated it in pure Python for fun (and slower results).

(Edit: As others have pointed out, I'm talking about MicroPython, which is, itself written in C. The Microbit is so simple it might not use MicroPython, but I can't imagine the BBC Microbit team bothered to reinvent the wheel for this.)

Of course, if you don't mind that the lowest level code has got to be binary, and very few people are crazy enough to create that code with Python, then...

It begs another interesting question: Just how much of an OS can we get away with writing in Python.

And that question is answered both by RedHat Linux and Debian Linux - and the answer is that both are built with an awful lot of Python.

In contrast, Android is mostly Java with ~~lots of C~~ a C Linux kernel. Windows is mostly C# and lots of C. iOS is mostly Objective C and lots of C.

You can have an OS built with almost any language you want, as long as you also want parts of it built in C. (Edit: This is meant to amuse you, not be guidance for what is possible. Today, we love our C code. C didn't always exist, and might someday no longer be our favorite hardware driving language.)

An interesting current development is discussion around rebuilding parts of the Linux Kernel with Rust, which can run just as fast as C. This would effectively cause RedHat, Debian and Android to replace some of their C code with Rust. To date, there's been a lot of interest and discussion and not a lot of (any?) actual funding or work completed.

I would not recommend this as an exercise for a beginner, but RPython is a subset of Python with a C backend; it is used as the basis of PyPy (an implementation of Python), so it may be possible to use it to implement the low-level parts which then can be used to bootstrap a full Python virtual machine.

What you are looking for is some way to shortcut the process of learning to write an operating system by re-using your existing knowledge of Python.

(I'm not judging that; I understand why you want to do it)

The simple truth is that there is no way to do that. Any solution that involves using Python in a kernel would cost you more in terms of complexity and time than learning C would.

It is rarely worth it to use a language outside of the domains that it is normally used for.

You could do some of it in Python, but some stuff needs low level access to registers, e.g. trap handlers and context switching.

Should you do that? Absolutely fucking not. It would be hilariously slow and inefficient. Hundreds of times, maybe thousands of times slower than C/C++ kernels.