Porting Python

[Tim Peters]

[Dave Abrahams]
> Suppose I wanted to build a version of python for a platform that's
> not yet supported. Does anyone have concise info on where the OS-
> dependencies are?  I'd like to get a sense of the scope of the job.

It's not OS-dependence so much as libc dependence -- Python does very little
under the covers that's not straight ANSI C.  The exceptions are generally in
modules that you don't *need* to build in (like threads and sockets -- and
those are designed to be "configured out" painlessly).

The only pervasive dependence is on malloc, realloc and free.  calloc is
declared for some historic reason, but last I checked is never actually
referenced.

Beyond those, Python needs enough of stdio to do text mode input of source
files and text mode output for "print", & binary I/O of compiled .pyc and .pyo
files.  So it needs too to open files, close them, and tell whether they
already exist.  This makes for obvious problems on platforms without
filesystems.

It assumes sizeof(int) is at least 4, but does not assume sizeof(long) is
bigger, or that sizeof(void*) is either of those, or that integral types and
pointers can be cast to the other (it plays no tricks at all with pointers).

People generally don't report major porting problems unless the platform C
implementation is insane; e.g., someone recently tried to port to an embedded
system whose OS and C runtime cleverly arranged to make all static vrbls shared
across processes(!).  Python doesn't have much static data, but what it does
have, it recklessly <ahem> assumes it owns.

What else?  Python likes to use memory, but you can feed it eat either live
rats or frozen ones without undue complaint.

pretending-we-never-met-ly y'rs  - tim