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

[Raymond Hettinger]

> 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".

That sounds reasonable.  Also, it reflects an understanding that "where
possible" sometimes means that:
- the maintainers are temporarily out of cycles,
- the discussion is on-going and not fully resolved,
- the real docs are more important that the PEP, and
- at some point, the implementation leads rather than lags the PEP.

In the case decorators, it sounds like all of these apply.  Also, it
would seem that the primary interest in the pep is to frame on going
arguments.  IOW, this would not be the last update.

With genexps, the information for the final pep update was not even
available until the patch discussion and newsgroup discussion wound
down.  Brett can attest to the difficulty of summarizing a voluminous
discussion that has not reached resolution.  Interestingly, after the
genexp update, no one seemed to care about or even read it.  Everything
they wanted to know had already been discussed ad nauseum or written it
the docs.

One other thought is that peps implemented in phases seem to get
neglected.  I don't think either Sets or Unifying Int/Long is current.



Raymond