autumn. Beta versions are already available from

\section{New Development Process}

The most important change in Python 2.0 may not be to the code at all,

but to how Python is developed.

In May of 2000, the Python CVS tree was moved to SourceForge.

Previously, there were roughly 7 or so people who had write access to

the CVS tree, and all patches had to be inspected and checked in by

one of the people on this short list. Obviously, this wasn't very

scalable. By moving the CVS tree to SourceForge, it became possible

to grant write access to more people; as of September 2000 there were

27 people able to check in changes, a fourfold increase. This makes

possible large-scale changes that wouldn't be attempted if they'd have

to be filtered through the small group of core developers. For

example, one day Peter Schneider-Kamp took it into his head to drop

K\&R C compatibility and convert the C source for Python to ANSI

C. After getting approval on the python-dev mailing list, he launched

into a flurry of checkins that lasted about a week, other developers

joined in to help, and the job was done. If there were only 5 people

with write access, probably that task would have been viewed as

``nice, but not worth the time and effort needed'' and it wouldn't

never have been done.

SourceForge also provides tools for tracking bug and patch

submissions, and in combination with the public CVS tree, they've

resulted in a remarkable increase in the speed of development.

Patches now get submitted, commented on, revised by people other than

the original submitter, and bounced back and forth between people

until the patch is deemed worth checking in. This didn't come without

a cost: developers now have more e-mail to deal with, more mailing

lists to follow, and special tools had to be written for the new

environment. For example, SourceForge sends default patch and bug

notification e-mail messages that are completely unhelpful, so Ka-Ping

Yee wrote an HTML screen-scraper that sends more useful messages.

The ease of adding code caused a few initial growing pains, such as

code was checked in before it was ready or without getting clear

agreement from the developer group. The approval process that has

emerged is somewhat similar to that used by the Apache group.

Developers can vote +1, +0, -0, or -1 on a patch; +1 and -1 denote

acceptance or rejection, while +0 and -0 mean the developer is mostly

indifferent to the change, though with a slight positive or negative

slant. The most significant change from the Apache model is that

Guido van Rossum, who has Benevolent Dictator For Life status, can

ignore the votes of the other developers and approve or reject a

change, effectively giving him a +Infinity / -Infinity vote.

Producing an actual patch is the last step in adding a new feature,

and is usually easy compared to the earlier task of coming up with a

good design. Discussions of new features can often explode into

lengthy mailing list threads, making the discussion hard to follow,

and no one can read every posting to python-dev. Therefore, a

relatively formal process has been set up to write Python Enhancement

Proposals (PEPs), modelled on the Internet RFC process. PEPs are

draft documents that describe a proposed new feature, and are

continually revised until the community reaches a consensus, either

accepting or rejecting the proposal. Quoting from the introduction to

PEP 1, ``PEP Purpose and Guidelines'':

\begin{quotation}

PEP stands for Python Enhancement Proposal. A PEP is a design

document providing information to the Python community, or

describing a new feature for Python. The PEP should provide a

concise technical specification of the feature and a rationale for

the feature.

We intend PEPs to be the primary mechanisms for proposing new

features, for collecting community input on an issue, and for

documenting the design decisions that have gone into Python. The

PEP author is responsible for building consensus within the

community and documenting dissenting opinions.

\end{quotation}

Read the rest of PEP 1 for the details of the PEP editorial process,

style, and format. PEPs are kept in the Python CVS tree on

SourceForge, though they're not part of the Python 2.0 distribution,

and are also available in HTML form from

\url{http://python.sourceforge.net/peps/}. As of September 2000,

there are 25 PEPS, ranging from PEP 201, ``Lockstep Iteration'', to

PEP 225, ``Elementwise/Objectwise Operators''.

To report bugs or submit patches for Python 2.0, use the bug tracking

and patch manager tools available from the SourceForge project page,

at \url{http://sourceforge.net/projects/python/}.