Is a python os possible?

[Jack_9]

In my opinion, python is a fantastic language, but is it possible to develop an operating system with python, BUT one thing that I do know is that if you were going to develop something with python it would probably have to be the gui. Because python dosen't even really touch the hardware of the computer (unlike C, C++, and Assembly) Who agrees with me? Who disagrees?

[Gribouillis]

One part of the question is why would we need an OS written in python ?

My advice is: go linux !

[vegaseat]

Python is a high level language, really not written to do low level access needed for OS use like C.

There have been past attempts ...
https://github.com/tornewuff/pycorn

[Hiroshe]

You certianly can't write the entire thing in python. You might actually be able to program a hunk of the kernal in a minimallistic python environment though.

Basically, you'll need to strip python down to the interpreter, compile it to an elf, and link that with your own C and assembly to satisfy the minimum requirements (malloc, free, printing functionality, etc...) and extentions for managing the hardware (basic drivers, memory management, scheduler, etc..). Then you'd write your bootloader to set up the momory, scan the FS, and load the kernal into memory as well as the script that glues it all togeather.

It would probably be better to set up a ctypes-like system as the only real extention, and then dynamically load other C/Assenbly code.

I wouldn't say this is the smartest idea though. A kernal written in a compiled language and assembly will be faster, and it won't amount to too much more effort to write. Also, using a JIT might be pretty difficult to set up without first setting up other resources.

It is very plausable to make an OS who's system language is Python though. You can write a shell, and all the tools in python just fine. If it ever needs speed, drivers or the ability to run binary programs, you can still use C via ffi.

You can also make python a standard language in an OS (like android and java for example). This would probably be the most practical.

[mike_2000_17]

The fact that most Python libraries are written either in C or C++ (or Fortran for NumPy / SciPy / ..) should tell you something about the limitations of Python as a system language. Thinking that Python is appropriate as a system programming language is missing the point of Python altogether, it's not understanding its strengths.

Having been exposed to some of the details of how operating system kernels and drivers are written, I can tell you that this can definitely not be done in a high-level language like Python. And even if you really wanted to, you would have to strip away many aspects of Python to the point that it wouldn't really be recognizable as such, it would become essentially a C-like language with Python syntax. And what would be the point of that? We have C already which has a syntax everyone is familiar with. I could imagine a stricter and more feature-rich language being used instead of C, maybe something like Embedded C++, but that's about as far as I think it could even go away from a low-level C-like language.

There are a number of things that are very common in kernel programming, which are, for the most part, impossible in Python (AFAIK). For one, having direct memory control and addressing. Remember, much of kernel code runs without virtual addressing (directly accessing physical memory addresses), and thus, need to manage and map their memory space precisely, byte-per-byte. This rules out any language that does not provide such low-level memory control (e.g., pointers, pointer arithmetic, memory alignment control, value-semantics, strictly defined memory layouts (ABI), etc..).

Another core aspect of much of kernel or driver programming is the limitations on dynamic memory allocations, sometimes down to not being used at all (only stack memory can be used). Also, there are often several special memory allocation methods used (e.g., from short-lived to persistent, from large to small), and the ability to select it is important (in actuality, it is often in the form of several different variations of malloc()/free() C functions depending on the allocator invoked). This means that a highly dynamic language (such as Python), which, by definition, relies heavily on dynamic memory allocations, would be a very bad fit to begin with, and would need to be significantly mangled or changed to become usable in such environments.

Another obvious problem is efficiency. As we all know, the expression "efficient Python code" is synonymous with "C/C++/Fortran code with Python bindings". Python has many great strengths, but efficiency simply isn't one of them.

Another thing to understand about kernel / driver programming is that they use some very awesome techniques that once you look into them, you realize that they comprise of a very tight integration of algorithmic logic and finely tuned design of the memory layouts of the data structures used. Things like non-blocking queues and buffers, task schedulers, online / concurrent file-system optimizers, etc., are some very tricky things to write, and they are too critical and low-level to be even imaginable in Python.

At this point, you could say that we could implement the core kernel code that is the most critical and constrained in C, as well as those drivers or modules that require physical addressing (e.g., tweaking with registers and hardware interrupts). But if you do that, there won't be much left to do in Python, because this is most of what the kernel does. And at that point, if you've already written 95% of the kernel in C, what would be the point of doing the other 5% in Python, with all the maintenance and portability problems that come with adding a second language (second compiler, second set of libraries to link to, second set of language standards to observe, etc..).

However, beyond the level of the kernel, there is probably a lot of room for Python, and it's been used quite a bit in those spheres. A lot of Linux desktop environments rely heavily on Python, mostly as a very convenient and dynamic "glue" language for components. Traditionally, of course, most of the user-space programs and libraries that make up the entire operating system (not just the kernel), such as GNU utilities and libraries, are still programmed in C or C++, but I could easily conceive many of those being Python programs. Also, it wouldn't be completely insane to have a Python interpreter built into the operating system, even in kernel-space, and have Python be essentially the "native" language of the operating system, much like Objective-C is the "native" language in Apple OSes. But, I said, it would not be completely insane, but still pretty crazy. I think that Python serves very nicely where it is, as one of the core languages used and one of the well-supported interpreters you find everywhere, i.e., your Pythons programs are first-class citizens pretty much everywhere they go.

Also, I'm not sure how much Python can be trusted in terms of strict correctness, well-defined behavior, and standard compliance of implementations (compilers / interpreters and libraries), which are extremely important things when you are talking about developing industrial-strength operating system code. AFAIK, Python hasn't been tested too heavily yet (at least, it doesn't have 30+ years of testing and billions of LOCs written, like C or C++).