Talk:Porting Python

Correct me if I'm wrong, but Python 2.5 is way out of date. 2.6, not as much, but still..

--Kotuxguy 06:14, 22 February 2010 (UTC)

This tutorial works for 2.5 and 2.6. It hasn't been tested on 2.7 (as that is still in alpha), and I don't consider 3.0 worth discussing yet. Python 2.5.5 was released on January 31 2010.

If you'd like to contribute a tutorial for Python 3.0 rather than just complaining about nothing, be my guest ;)

--pcmattman 06:48, 22 February 2010 (UTC)

Fair enough. I'll work on it as soon as I get my OS to that stage.

--Kotuxguy 06:25, 23 February 2010 (UTC)

Regarding the stage required for porting Python, in our OS, Python (strictly core python lib only) was the 3rd user mode program ever for our OS, after Hello World and 99 bottles of beer. Required porting newlib, and a way to build statically linked binaries for usermode, basic paging and processes - we did not do complete elf loader but just an easy format based on a custom linker script with all 3 sections at page aligned locations and 4k header. We did not have filesystem support either, only write and exit system calls were fully implemented in newlib. The executable in question originally initialized Python 2.5 interpreter and executed a python "hello world" script that was hardcoded in the executable. When we noticed that we really need filesystem for many modules to work correctly, only then we implemented FAT readonly support for ram disks :)

--Ztane 11:27, 26 February 2010 (UTC)

Sure, it is possible to port Python with a very minimal libc. However, as you found out, without more than just the basic support in your libc you run into a lot of restrictions with Python (specifically, its modules). For example, you can't port modules which use networking until you write a Berkeley sockets layer.

The reason I decided to label this tutorial "Advanced" and imply a requirement of more than just a rudimentary libc is simply because the understanding of the toolchain, configure process, and library calls that comes from more experience with porting and using other software is very, very useful here.

--pcmattman 23:34, 26 February 2010 (UTC)

Pcmattman, you are absolutely right, and I do not deny it does not require knowledge of porting, toolchain and system calls etc. But if you can do it, have toolchain and full libc with only some system calls (write, exit, sbrk), it might be useful, even if you do not yet have networking, or even filesystem code. My friend and I are very lazy and we just did not have that much time to implement every imaginable system call, before trying to port something to our OS. The beauty of porting python at this early stage for us is that we have an easy way to write a complex test program - just a few lines of python, which, under the hood will require lots of processing and also serve as a stress test. So first, we got to test if our newlib behaves acceptably with python, returning proper error codes from open, etc, and got a rather complicated test for our sbrk. So when we implemented the read only file system, we had already some test cases for it, that is, had to make python module imports for builtin modules to work, and to load userland initialization script from /init.py. I myself did not even believe we could get libpython itself to work with such minimal hacking in our 3-system call (write, sbrk, exit IIRC) environment, but it really did work. The only problem we had was some warning message telling that python cannot find its site libraries.

--Ztane 08:21, 28 February 2010 (UTC)