On Sat, Nov 3, 2012 at 3:29 AM, Terry Reedy <tjre...@udel.edu> wrote: >> The way to resolve a proposal >> >> like that is to put it forward as a PEP, and explain the rationale for >> treating IDLE differently. > > > A PEP seems like overkill to me. The matter is a rule clarification, not an > enhancement proposal. The rationale is simple.
If you don't want to run the risk of needing to rehash this discussion every time an IDLE feature addition is made in maintenance branches, write the rules down in a PEP. I don't actually care all that much about IDLE (except in an abstract "I know other people care about it" sense), but I *do* care about developers being able to understand the rules about whether or not a feature addition is permissible in a maintenance branch. That kind of thing *cannot* be left to "oh, this change is OK, this change isn't, but you needed to be around for this discussion that happened 5 years ago in order to understand why", because it *wastes everybody's time* explaining the unwritten rules to new developers. If there is a part of the code base where new features are permitted in maintenance branches, write them down, get agreement on them, and if anyone complains "but that's a new feature on a maintenance branch", point them to the PEP that says its OK. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
