[Python-3000] feature proposal process
brett at python.org
Tue Mar 21 06:19:36 CET 2006
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
More information about the Python-3000