History of Python

Guido van Rossum started to write Python in December 1989.

History of Python releases

See also Status of Python branches.

  • Python 3.8: October 2019
  • Python 3.7: June 2018
  • Python 3.6: December 2016
  • Python 3.5: September 2015
  • Python 3.4: March 2014
  • Python 3.3: September 2012
  • Python 3.2: February 2011
  • Python 2.7: July 2010
  • Python 3.1: June 2009
  • Python 3.0: December 2008
  • Python 2.6: October 2008
  • Python 2.5: September 2006
  • Python 2.4: March 2005
  • Python 2.3: July 2003
  • Python 2.2: December 2001
  • Python 2.1: April 2001
  • Python 2.0: October 2000
  • Python 1.5: April 1999

History of the Python language (syntax)

Old Python Versions

Development before GitHub

Buildbot was only running after changes were pushed upstream. It was common that a change broke the Windows support, and so core devs pushed an “attempt to fix Windows” commit, and then a second one, etc.

To propose a change, a contributor had to open an issue in the bug tracker (Roundup at bugs.python.org), and attach a patch file. A core developer had to

  • Download the patch locally
  • Apply the patch file
  • Fix conflicts: when the day was older than 1 day, conflicts were very likely

Misc/NEWS was basically always in conflict, especially on merges.

Changes were first fixed in the oldest supported branch, and then forward-ported to newer branches. For example, fixed in 2.6, and ported to 2.7, 3.0 and 3.1.

When Subversion was used, a Subversion “property” (in practice, a text file tracked by Subversion) listed the revision number of all “merged” changes. For example, when a change made in the 2.6 branch was merged into the 2.7 branch, it was added to this list. It was likely that this property file was in conflict. Sadly, it was a text file made of a single line with thousands of revision numbers. Text editors are not convenient to edit such file. It was barely possible to fix a conflict in this property.

A new tool to review (comment) patches was linked to Roundup: Rietveld. It was possible to generate a patch from a fork the Mercurial repository, and then get a review page. Rietveld supported multiple revisions of the same change. Drawback: the tool was not well integrated with Roundup. For example, there was no way to unsubscribe from a review.

CVS, Subversion, Mercurial