On 15 July 2015 at 12:07, Steven D'Aprano <st...@pearwood.info> wrote: > On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote: > >> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more >> obnoxious behavours we can inflict on fellow open source maintainers >> giving us the gift of their time and energy. > > Nick makes a good point, but it's more complicated than that. > > OpenSource is not just a family of licences. It is also a social > movement, a culture, even a brand. We spend a lot of effort trying to > get people to care, not just intellectually but also emotionally, and > then when they react emotionally we're dismissive and tell them they're > being obnoxious. Maybe they are, but if so, that's the price you pay for > having people care.
Aye, there's definitely a balance to be struck (and *me* telling folks not to be passionate about topics they care about would be the height of hypocrisy). The kinds of questions I'm encouraging folks to ask themselves to help calibrate our degree of concern are: * What change are we asking for? * What will the practical end user benefit of that change be? * What will the near term maintainer cost of that change be? * What will the long term maintainer benefit of that change be? Those are the questions other people are going to want answers to anyway, so it makes sense to ask them of ourselves first. In the case of partially reverting this change to Mock objects, the answers are: * "Restoring support for 'assret_*' methods on Mock objects" * "End users will be able to access their 'assret_*' methods on Mock objects" * "Maintainers would need to modify the check itself and the related tests and documentation" * "Maintainers won't have to explain why 'assret_*' methods are blocked and other 'assert_*' typos aren't" Thus, the case for spending *any* time on reversion is incredibly weak, even if folks agree with the premise that blocking *any* typos at all is undesirable. Robert's suggestion is different, as it focuses on addressing the near term concern with a solution that genuinely improves the API design: * "Move Mock assertions from methods to module functions" * "End users will gain from clear structural separation between Mock'ed methods and Mock assertions, such that method name typos don't result in silently ignoring test failures" * "Maintainers would need to design the new API and device a recommended transition plan for end users that accounts for end users wanting to support multiple Python versions" * "Once the migration from the old API to the new API is deemed complete, maintainers should eventually find that the improved separation of concerns between Mock'ed methods and Mock assertions makes the module easier to maintain" Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com