[Python-3000] feature proposal process

[Brett Cannon]

It seems to me that we should follow the normal process we have been
following on python-dev; library changes can just be done by the
discretion of committers and language changes require a PEP.

I guess the real question is how stringent we should be with the PEP
process.  For instance, do we really need a PEP for changing
dict.keys() to return an iterator and to drop dict.iterkeys()?  This
has been planned for so long, I say it is not needed.  PEP 3000 can be
augmented to make sure all obvious changes have a basic explanation.

But what about situations like changing dict.keys() to an attribute? 
Does that require a full PEP?  Since mutation is not expected during
iteration on the returned iterator, I say it should be an attribute. 
But I am not sure if that idea should be back up by me thinking that a
general design idea that something that returns immutable information
should come from an attribute should be enshrined in a PEP describing
general Py3K design principles or as a separate PEP describing overall
planned changes to dict.

It probably wouldn't hurt to write a general guidelines PEP in terms
of design.  Obviously it would not be hard rules or authoratative, but
stuff like what should be an attribute compared to a function with no
arguments might be helpful.  Also gives us a clear idea of where
things should go in terms of directioninstead of relying on Guido
spilling his brain every so often (obviously Guido should be the
primary author of a PEP like this).

The over-arching question I am posing is how granular we should be
with the PEPs.  Should some meta-PEPs in terms of design be hashed out
first so we have general guidelines to follow.  I say we should get at
least some rough ideas down.

After that we should probably have a PEP for each of the core built-in
types to cover exactly what the API is that we want.  I doubt they
will change much beyond the API so these shouldn't be major, but it
will provide a good overview of what is and isn't lacking in them at
the moment.

-Brett