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

Jeremy Hylton jhylton at gmail.com
Fri Aug 6 04:18:53 CEST 2004


On Fri, 06 Aug 2004 11:21:32 +1000, Anthony Baxter
<anthony at interlink.com.au> wrote:
> 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 answer would be before checkin unless there is widespread consensus
or there's only one obvious way to do it.  Developer time is a scarce
resource.  Checking in code without having a decent PEP, particularly
for major changes or new features, just wastes everyone's time.  We
spend hundreds of hours, collectively, repeating old debates and
speculating about why something was done the way it was.  Since no one
(?) is doing Python development as a day job, it's particularly
important that we make effective use of our spare time.

A PEP makes the development process more heavyweight -- but that was
its primary goal.  We wanted to make sure the specification and
rationale got written ahead of time.  Then other developers would know
what's happening, the spec would actually provide the new words for
the language ref (do we have that for decorators or genexps?), and
we'd be sure that the developer had thought through all the issues.

Jeremy


More information about the Python-Dev mailing list