[Python-Dev] PEP 318, and the PEP process

[Anthony Baxter]

I'm extremely averse to making the Python development
process any heavier than it has to be, but the complaint
that PEP 318 should have been updated to the state of
play before the checkin is a fair complaint. I'm not
sure what the best approach here is - should we make
a motherhood-and-apple-pie statement that, all things
being equal, a PEP should be updated before the code
it documents is checked in? Should we aim to have it
done before the first release including the code? Before
the first _final_ release that includes the code?

My answers would be "before checkin, where possible;
before first alpha/beta release, where really possible;
before first final release, absolutely".

Having said that, I don't think the lack of completed
PEP is a reason to back out the @ syntax from CVS. If
nothing else, it being present in a released alpha is
giving us very real experience with the use of the
feature. There's also the issue that there's a bunch
of other existing PEPs describing features that aren't
up to date at all.

Which brings up another related point: Many PEPs
contain "open issues" and the like, that are never
ever backfilled. Largely this is a matter of round
tuits - the PEP authors are generally drawn from a
very small group of developers. How can we encourage
other people to contribute to this? The obvious way
(to me) is some form of Wiki annotation. I don't
think we want to make the Wiki the primary copy of
the document, but I think having the PEPs annotatable
would be a win.


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.