On 21 October 2016 at 15:26, Nick Coghlan <ncogh...@gmail.com> wrote: > - Remember that even if something we vehemently consider "wrong" makes > it into the reference implementation, the language does have a design > policy that allows us to correct design mistakes after a suitable > deprecation period, and we also each personally have the option of > advocating for updates to the coding styles on the projects we > participate in to prohibit use of the features we consider problematic
This one, I think is particularly relevant to long-time participants (I know it applies to me). It's very easy to become strongly defensive out of fear that a chorus of enthusiasm will push something through that you disagree with. It's worth people (me!) remembering that there's a large "silent majority" of people who don't participate on python-ideas, but who have a strong influence on whether proposals get accepted. Also, the tracker and the PEP process do a great job of sanity checking proposals. So there's no need for people to feel like they have to be the lone defender of the language against wild proposals. > The reason it's useful to have a > brainstorming list where folks may be told "That's a bad idea for > Python", but should never be told "You shouldn't have suggested that", > is that sometimes someone will challenge a longstanding assumption > that isn't actually true anymore, or an accident of implementation > that imposes an unnecessary stumbling block for new users. In those > cases, the net future benefit to the overall ecosystem may be judged > significant enough to be worth the costs of adjusting to it. I wonder. Would there be value in adding a sign-up email to the list (supported by a posting of that email to the list, to catch existing contributors) that set out some of the basic principles of how changes are judged for inclusion in Python? We could cover things like: * The fact that the default answer is typically "no", along with an overview of the reasons *why* the status quo wins by default. * Some of the simple "rules of thumb" like "not every 2-line function should be a builtin. * Basic reminders that Python is used by a very diverse set of users, and proposals that are only beneficial for a limited group need to be weighed against the disruption to the majority who get no benefit. * The above comment, that we welcome ideas because it's important that we don't stagnate and having assumptions challenged is valuable, even if the bar for getting such ideas accepted is (necessarily) high. Maybe even make it a regular informational posting, if it seems that a reminder would be useful. It's possible that this would come across as too bureaucratic for new users, though, so I'm not sure... Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
