On 19 October 2016 at 21:29, Michel Desmoulin <desmoulinmic...@gmail.com> wrote: > +1. > > I read many disagreements, and people being rude and unprofessional on > occasions, but nothing that would make me have a bad day, even when I was > the target of it. > > I feel like people are really getting hyper sensitive about communications.
As Paul says, assuming good intent is highly desirable, but at the same time, we need to fully appreciate as post authors that python-ideas is a shared communications channel where hundreds of other people are offering us their time and attention for the shared purpose of attempting to ensure that future versions of Python offer an even better programming environment for all kinds of programmers. Respecting that means learning to somehow balance the interests of kids taking their first steps into programming with MicroPython on the micro:bit, adults picking up Python as a possible first step in pursuing a career change, professional web service developers wringing every last ounce of performance out of PyPy that they can, scientists & analysts trying to make sense of their data sets in CPython, system administrators and infrastructure engineers automating their daily activities, etc, etc. Sure, many of us are mainly here because we'd like to make future versions of Python better for ourselves as individuals, but the sheer scope of Python's existing adoption means we're all operating under the basic constraint that even unambiguously positive changes impose non-trivial costs on the rest of the ecosystem, as other implementations need to be updated, books, course notes, and other educational materials require changes, and every current Pythonista gains a new thing to keep in mind where they're wondering which features they can and can't rely on when targeting particular versions. Even the consequences for future Pythonistas aren't unambiguously good, as they'll not only gain a new capability that they'll learn in newer versions, and then have to unlearn when maintaining software written to also run on older versions, but will also often receive confusing advice from folks that first learned an earlier version of Python, and may not have kept up with all of the changes in more recent versions. This constraint is exacerbated by the fact that we're still in the midst of the Python 3 migration, where many of our current users still have software compatibility hurdles between them and their ability to benefit from the work being done on the Python 3 series. This all means that with "post your language design ideas for collaborative critique" being an inherently conflict prone activity, and with "No, that's not a good fit for Python" being such a common answer, it takes a lot of collective effort for us to ensure that this remains a primarily positive and rewarding experience both for folks posting suggestions for change, and for folks reviewing and commenting on those suggestions. In practice, this mainly boils down to attempting to follow the guidelines: - Don't make people regret posting their idea (however much we personally dislike it) - Be willing to graciously accept 'No' for an answer when posting a suggestion for change - Remember that fixing problems just for ourselves and folks that choose to adopt our solution is a perfectly fine option - we don't necessarily have to change the default characteristics of the entire language ecosystem - 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 Cheers, Nick. P.S. Given the existence of the constraints discussed above, folks may then be curious as to why we have a brainstorming list at all, given that the default answer is almost always going to be "No", with folks being encouraged to instead find a way to use the existing flexibility in the language and interpreter design to solve the problem to their own satisfaction in a 3rd party module or even a language variant (with MacroPy and Hylang being a couple of significant examples of folks taking that path for ideas that would never be accepted into the default implementation). 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. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
