This morning, I decided to try to install Python 1.0. I wanted to get a glimpse of where the language came from, how it's grown, and what it was like in its early days. I figured an earlier version would probably be a little simpler, and perhaps the codebase would be easier to understand.
Browsing the downloads page of python.org, I found binaries going back to 1.2 for several processors. There was even one 1.1 binary for an architecture I'd never heard of called sequent-pts. This maybe? On another page, they had source releases going back to 1.0.1, with a note saying:
If you find an older Python release (e.g. 0.9.8), we're interested in getting a copy! firstname.lastname@example.org
I figured there was little chance of getting one of the binaries working out of the box, plus the source releases go back further, so I grabbed a copy of 1.0.1. The first thing I noticed was that the whole tarball weighs in at 1.1MB, compared to 19MB for the latest version, Python 3.4.
The organization of the code did not seem unusual; the base directory had the usual configure and Makefile, as well as a README file with some brief release notes, build instructions, and a guide to the organization of the source code. According to the copyright file, Python was originally created in 1991, and this version came out in 1994. Twenty years ago.
One amusing note from the README: apparently Guido van Rossum did not feel the need for handholding newbies back then. There's a section about compiling readline support into python, in which he says:
You can use the GNU readline library to improve the interactive user interface: this gives you line editing and command history when calling python interactively. You need to build the GNU readline library before running the configure script. Its sources are distributed with Python. This may involve some editing of the Makefile there -- I'm sorry, but I don't feel responsible for making it more portable or adapting it to autoconf...
The pieces are there, but it hasn't actually been hooked up, and doing so is left as an exercise for the reader. (I may try my hand at that exercise; it sounds like a fun learning experience).
Next, I decided to try actually compiling the thing. According to the docs, it just required the usual:
$ ./configure --prefix=~ $ make $ make install
plus an extra
$ make libinstall
Unfortunately, make failed with gcc complaining that the function getline was defined twice with incompatible declarations. Apparently, python defined its own getline in one file, even though it already exists in stdio.h. Maybe it didn't back then. Looking at the source for stdio.h, it seemed that the standard lib getline could be removed by unsetting the __USE_XOPEN2K8 macro. I tried to do that a couple ways, but apparently was having trouble finding the right place to put it so that it would be undefined by the time stdio.h was included. I'm sure I could figure it out, but I was eager to get going, and it was easier just to rename python's getline function to _getline instead. With that done, I was able to build the whole thing with no trouble. The entire build, ./configure && make, took a whopping seven seconds.
I was surprised at how easy it was. So I installed the resulting binary, and fired it up.
~/Downloads/python-1.0.1$ ~/bin/python Python 1.0.1 (Mar 23 2014) Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam Segmentation fault
My first guess is that it's complaining because I compiled it on a 64-bit system, and it was only built to handle 32-bit architectures. That's as far as I've gotten so far. Figuring that out will be my next task. I might try to compile it against 32-bit libraries, or I might see how much work it would take to create a x86_64 port. The release notes say that the 1.0 release involved a lot of work porting python to different architectures, so hopefully most of the heavy lifting is done.
So far, perusing this codebase has been a fascinating glimpse into the history of Python, both the language itself, and how the core Python community saw itself in the greater open source and Unix ecosystems of the time. I'm looking forward to exploring further.