Tuesday, January 20, 2009

A Brief Timeline of Python

The development of Python occurred at a time when many other dynamic (and open-source) programming languages such as Tcl, Perl, and (much later) Ruby were also being actively developed and gaining popularity. To help put Python in its proper historical perspective, the following list shows the release history of Python. The earliest dates are approximate as I didn't consistently record all events:

Release DateVersion
December, 1989Implementation started
1990Internal releases at CWI
February 20, 19910.9.0 (released to alt.sources)
February, 19910.9.1
Autumn, 19910.9.2
December 24, 19910.9.4
January 2, 19920.9.5 (Macintosh only)
April 6, 19920.9.6
Unknown, 19920.9.7beta
January 9, 19930.9.8
July 29, 19930.9.9
January 26, 19941.0.0
February 15, 19941.0.2
May 4, 19941.0.3
July 14, 19941.0.4
October 11, 19941.1
November 10, 19941.1.1
April 13, 19951.2
October 13, 19951.3
October 25, 19961.4
January 3, 19981.5
October 31, 19981.5.1
April 13, 19991.5.2
September 5, 20001.6
October 16, 20002.0
February 25, 20011.6.1
April 17, 20012.1
December 21, 20012.2
July 29, 20032.3
November 30, 20042.4
September 16, 20062.5
October 1, 20082.6
December 3, 20083.0
I've added hyperlinks to the releases that are still being advertised on python.org at this time. Note that many releases were followed by several micro-releases, e.g. 2.0.1; I haven't bothered to include these in the table as otherwise it would become too long. Source tarball of very old releases are also still accessible, here: http://www.python.org/ftp/python/src/. Various ancient binary releases and other historical artefacts can still be found by going one level up from there.


  1. I think the coolest way to visualize Python's history is through code_swarm:


  2. a) how long did it take you to realize the "range" function is using huge amounts of memory when used in a for loop ? Did you not envison people needing more than a few iterations ? If there should only be one way to do something, why have both range and xrange ?

    b) When are you going to add File.open ?

    c) how many more special reserved words are you going to use for "built-in" functions, and are there going to be any "free" names left for people to use in their programs without fear of conflict ?

    d) how many more upgy underscore methods are you going to hack into the "language" ?

    e) why is everything about this "language" so hacky and provide a million different ways to do the same thing (get/getattr/hasattr/has_key/in/etc) ?

    f) Is the motivation behind the "property" function/decorator/object? to win the most stupid syntax ever ?

    when are you going

  3. Wish all these subversion repositories would quickly move onto a DVCS, like git.

    Tired of using $ git svn, to slowly painfully accumulate history.

  4. @Uzah:

    b) what's wrong with open() ? it could conceivably return more than files. in 3.0, it returns an io.BufferedReader.

    c) built in functions are not reserved words. you can define your own function called open, and you can use a local variable called open without any problems.

    d) ugly underscore methods? methods of what? what are you talking about?

    e) they all do very different things (except for has_key, which is going away).

    f) it's nice precisely because it doesn't introduce new syntax.

  5. Uzah, when will you stop beating your wife?


Note: Only a member of this blog may post a comment.