[Python-3000] feature proposal process

[Samuele Pedroni]

Brett Cannon wrote:
> 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. 


uh? it produces a fresh iterator each time tough. I cannot recall 
anything like this that follow your philophy at the moment.

I think that mixing your ideas with process discussion is a mistake.
(or was it an weird example)

> 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
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/pedronis%40strakt.com