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 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.
Python 1.0.1 (Mar 23 2014)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
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.
There are comments.